DEV Community: Marcelo Lino

Argumentos Opcionais Mutáveis em Python

Marcelo Lino — Mon, 27 Feb 2023 18:30:18 +0000

Argumentos deveriam ser coisas simples, não é mesmo? Você passa um valor para a função e ela faz o que você espera. Mas o que acontece quando a sua função não te obriga a passar um valor e trabalha com um valor padrão?

Uma função de soma que recebe dois valores e retorna a soma deles, porém caso nenhum valor seja inserido os argumentos assumem o valor 10 para cada um, retornando assim 20.

def soma(a=10, b=10):
    return a + b

Nesse exemplo os valores padrões são imutáveis, então a cada operação não há modificação no seu conteúdo.

Agora o que acontece se modificamos o valor padrão para uma lista ou um dicionário?

Problema

from random import randint

def mutable_arguments(a_list=[], a_dict={}):
    a_list.append(randint(0, 100))
    a_dict[randint(0, 100)] = randint(0, 100)

    print(f"A lista agora contém os seguintes items: {a_list}")
    print(f"O dicionário agora contém os seguintes items: {a_dict}", end="\n\n")

mutable_arguments()
mutable_arguments()
mutable_arguments()

Essa execução gera a seguinte saída:

The local list a_list now contains: [43]
The local dict a_dict now contains: {50: 61}

The local list a_list now contains: [43, 74]
The local dict a_dict now contains: {50: 61, 128: 69}

The local list a_list now contains: [43, 74, 42]
The local dict a_dict now contains: {50: 61, 128: 69, 86: 79}

Note que a cada execução a lista e o dicionário são modificados, isso acontece porque o interpretador do Python aloca cada função ou método na inicialização do programa, caso essa assinatura contenha inicializadores de objetos eles então serão instanciados e alocados em memória durante a inicialização.

Sendo assim, quando você executa seu código e altera esses mesmos valores, está alterando objetos já alocados e não criando novos a cada execução. O que pode ao final do programa gerar resultados inesperados.

Solução

Existem duas formas de resolver esse problema, a primeira é passar None como valor padrão e então verificar se o valor é None e então atribuir o valor padrão.

from random import randint

def immutable_arguments(a_list=None, a_dict=None):
    if a_list is None:
        a_list = []
    if a_dict is None:
        a_dict = {}

    a_list.append(randint(0, 100))
    a_dict[randint(0, 100)] = randint(0, 100)

    print(f"A lista agora contém os seguintes items: {a_list}")
    print(f"O dicionário agora contém os seguintes items: {a_dict}", end="\n\n")

immutable_arguments()
immutable_arguments()
immutable_arguments()

Outra abordagem é reatribuir o valor padrão ou então um objeto mutável vazio.

from random import randint

def immutable_arguments(a_list=None, a_dict=None):
    a_list = a_list or []
    a_dict = a_dict or {}

    a_list.append(randint(0, 100))
    a_dict[randint(0, 100)] = randint(0, 100)

    print(f"A lista agora contém os seguintes items: {a_list}")
    print(f"O dicionário agora contém os seguintes items: {a_dict}", end="\n\n")

immutable_arguments()
immutable_arguments()
immutable_arguments()

Em ambos os casos a saída será a seguinte:

A lista agora contém os seguintes items: [44]
O dicionário agora contém os seguintes items: {7: 37}

A lista agora contém os seguintes items: [39]
O dicionário agora contém os seguintes items: {28: 50}

A lista agora contém os seguintes items: [40]
O dicionário agora contém os seguintes items: {40: 99}

Perceba que agora a cada execução os valores são reatribuídos e não mais modificados.

Migrações no Django sem Downtime

Marcelo Lino — Wed, 04 Jan 2023 15:16:01 +0000

Uma das coisas mais ferramentas mais poderosas do framework Django é o seu ORM e o gerenciamento de migrações. Porém quando enfrentamos um ambiente produtivo, por diversas vezes temos que executar migrações que adicionam, removem ou alteram colunas, o que causa uma indisponibilidade no sistema, até que o novo código que comporte essa nova estrutura do modelo esteja disponível para atender as requisições.

O fluxo de implantação de um novo código de aplicação Django geralmente consiste em:

O problema acontece pois entre a Execução da Migração e a Execução do Novo Código o Código Atual ainda estará em execução até que o novo possa assumir, fazendo com que o Django dispare um IntegrityError deixando todas as suas gravações de dados indisponíveis nesse período de tempo.

Pra solucionar esse problema temos alguns procedimentos que podemos seguir.

Adicionando Campos ou Tabelas

Adicionar um campo `NULL` ou nova tabela

Crie o modelo ou a coluna no seu código;
Gere as respectivas migrações com python manage.py makemigrations;
Faça duas Pull Requests, uma contendo a alteração do modelo e outra com a respectiva migração;
Faça o Merge e a implantação da Pull Request com a migração;
Execute a migração no seu banco de dados de produção. Adição de campos não deve causar problemas se o modelo em produção não esperar que esses campos estejam lá;
Faça o Merge da Pull Request com a mudança no modelo;
Implante o código com a mudança do modelo. A partir de agora o código vai começar a ler e escrever na nova coluna.

Adicionando um campo `NOT NULL`

Para iniciar a adição de um campo NÂO NULO, primeiro siga os passos acima adicionando ele como NULO inicialmente

Altere a coluna no modelo para null=False. Certifique-se que no seu código você não está inserindo ou atualizando esse campo com valores nulos;
Gere as respectivas migrações com python manage.py makemigrations;
Faça duas Pull Requests, uma contendo a alteração do modelo e outra com a respectiva migração;
Faça o Merge da Pull Request com a mudança no modelo;
Implante o código com a mudança do modelo. A partir de agora o código vai começar a gravar na nova coluna.
Faça o Merge e a implantação da Pull Request com a migração;
Execute a migração no seu banco de dados de produção.

Adicionando `NOT NULL` em tabelas com muitos dados

As migrações do Django insistem que se exista um valor default para colunas com a constraint NOT NULL. Esse valor será usado para popular as colunas vazias durante a migração. Esse processo de atualização efetuará um LOCK na tabela para escrita até que a atualização esteja concluída. Para tabelas pequenas com menos de 100.000 linhas, provavelmente não haverá problemas, porém para colunas com mais dados isso pode causar uma indisponibilidade do sistema até que a tabela esteja novamente disponível.

Afim de evitar esse comportamento, podemos executar Migrações Não Atômicas, simplesmente adicionando o atributo atomic = False a sua migração, como no exemplo a seguir.

from django.db import migrations

class Migration(migrations.Migration):
    atomic = False

Removendo Campos ou Tabelas

Removendo um campo `NULL` ou uma Tabela

Basicamente é o mesmo procedimento de adição, porém com os passo em uma ordem um pouco diferente.

Remova todas as utilizações do modelo ou coluna a serem removidas da sua aplicação;
Faça a implantação de uma versão que ainda tenha a definição da coluna ou modelo a ser removida, porém que não tenha mais a sua utilização;
Faça a remoção da coluna ou modelo do seu código;
Gere a migração para a remoção com python manage.py makemigrations;
Faça o Merge da mudança do modelo;
Implante o código da mudança do modelo. Certifique-se que não está ocorrendo nenhum erro por ainda existir alguma referência ao código que não mais existe;
Faça o Merge da migração;
Implante o código da migração;
Execute a migração no seu banco de dados.

Removendo um campo `NOT NULL`

Para remover um campo não nulo, primeiramente você tem que transformá-lo em um campo nulo, então seguir os passos a cima para remover um campo não nulo. Os passos para transformar o campo não nulo em nulo são:

Alterar o seu campo para null=True;
Criar as migrações para esse mudança;
Criar duas Pull Requests separadas, uma para a mudança no modelo e outra para migração;
Fazer o Merge e implantar o Pull Request com a migração;
Execute a migração no banco de dados;
Faça o Merge e a implantação da mudança do modelo;
Execute os passos para remover um campo nulo

Mais poder no seu Docker Compose

Marcelo Lino — Mon, 26 Sep 2022 14:45:47 +0000

Já podemos dar como certo que o docker está em um momento ou outro na vida de um programador, e muitas vezes nos utilizamos de arquivos docker-compose.yaml para executarmos localmente nossas aplicações e suas dependências e algumas vezes até em produção.

Por vezes temos que executar coisas mais complexas como executar uma migração de banco de dados antes da nossa aplicação executar, garantir que o banco de dados já esteja pronto para receber conexões, executar um subconjunto de dependências e assim por diante. Em muitas das minhas experiências vi esses requisitos serem executados através de scripts shell que nem sempre são familiares a todos os membros da equipe o que sempre gera uma estranheza e medo de extender tais funcionalidades, pensando nisso resolvi deixar mais evidentes algumas funcionalidades do Docker Compose que por muitas vezes são ignoradas.

Healthcheck

A especificação do Docker Compose conta com uma forma de healthcheck que podemos utilizar para garantir que nossa aplicação não só está rodando, mas como ela está operacional, essa checagem é útil quando queremos garantir que um serviço de ser executado somente após outro serviço estar totalmente operacional.

version: '3'

services:
  db:
    container_name: db
    image: postgres:alpine
    environment:
      - POSTGRES_PASSWORD=postgres
      - POSTGRES_USER=postgres
      - POSTGRES_DB=postgres
    volumes:
      - db_data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postgres"]
      interval: 5s
      timeout: 5s
      retries: 5

Definindo o banco de dados com esse healthcheck quando adicionarmos a definição da nossa aplicação podemos dizer que ao depender do banco ela só inicie após o serviço dependente estar de pé e saudável.

version: '3'

services:
  app:
    container_name: app
    build:
      context: .
      dockerfile: Dockerfile
    volumes:
      - .:/app
    ports:
      - "8000:8000"
    command: "gunicorn -b 0.0.0.0:8000 -k gevent sample.main:create_app() --access-logfile=- --preload -w 4"
    depends_on:
      db:
        condition: service_health
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:8000/healthcheck"]
      interval: 5s
      timeout: 30s
      retries: 5

  db:
    container_name: db
    image: postgres:alpine
    environment:
      - POSTGRES_PASSWORD=postgres
      - POSTGRES_USER=postgres
      - POSTGRES_DB=postgres
    volumes:
      - db_data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postgres"]
      interval: 5s
      timeout: 5s
      retries: 5

Profiles

As vezes nos deparamos com arquivos docker-compose.yaml extensos e com várias definições de serviço, porém ao desenvolver alguma funcionalidade necessitamos somente de um subconjunto desses serviços afim de testarmos nosso código, para isso temos os profiles

version: '3'

services:
  app:
    container_name: app
    build:
      context: .
      dockerfile: Dockerfile
    volumes:
      - .:/app
    ports:
      - "8000:8000"
    command: "gunicorn -b 0.0.0.0:8000 -k gevent sample.main:create_app() --access-logfile=- --preload -w 4"
    depends_on:
      db:
        condition: service_healthy
      profiles:
      - web
      - full
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:8000/healthcheck"]
      interval: 5s
      timeout: 30s
      retries: 5

  db:
    container_name: db
    image: postgres:alpine
    environment:
      - POSTGRES_PASSWORD=postgres
      - POSTGRES_USER=postgres
      - POSTGRES_DB=postgres
    profiles:
      - dependencies
      - web
      - full
    volumes:
      - db_data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postgres"]
      interval: 5s
      timeout: 5s
      retries: 5

Com essa definição podemos utilizar o comando docker-compose --profile dependencies up para iniciar somente a nossa base de dados.

Extensão

A mesma base de código muitas vezes pode ser utilizada para executar serviços em diferentes contextos, uma aplicação web, um serviço assíncrono de tarefas, uma execução única de linha de comando. Sendo assim é interessante para nós desenvolvedores definirmos uma base comum e somente personalizarmos para cada caso de uso.

Para atingir tal objetivo no Docker Compose temos a opção de usar um feature da própria

Ancora YAML

A especificação do YAML permite que criemos ancoras para reaproveitamento de definições, assim podemos criar uma base comum para um serviço para depois especializarmos.

version: '3'

x-app: &app
  build:
      context: .
      dockerfile: Dockerfile
  depends_on:
    db:
      condition: service_healthy
    queue:
      condition: service_healthy

services:
  app:
    <<: *app
    container_name: app
    volumes:
      - .:/app
    ports:
      - "8000:8000"
    command: "gunicorn -b 0.0.0.0:8000 -k gevent sample.main:create_app() --access-logfile=- --preload -w 4"
    profiles:
      - web
      - full
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:8000/healthcheck"]
      interval: 5s
      timeout: 30s
      retries: 5

  background:
    <<: *app
    container_name: background
    command: "celery -A sample.main:celery_app worker"
    environment:
      - CELERY_RESULT_BACKEND=redis://cache:6379/0
      - CELERY_BROKER_URL=amqp://guest:guest@queue:5672//
    profiles:
      - background
      - full

  db:
    container_name: db
    image: postgres:alpine
    environment:
      - POSTGRES_PASSWORD=postgres
      - POSTGRES_USER=postgres
      - POSTGRES_DB=postgres
    profiles:
      - dependencies
      - full
    volumes:
      - db_data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postgres"]
      interval: 5s
      timeout: 5s
      retries: 5

  queue:
    container_name: queue
    image: rabbitmq:3-management-alpine
    profiles:
      - dependencies
      - full
    healthcheck:
      test: ["CMD", "rabbitmq-diagnostics", "-q", "ping"]
      interval: 30s
      timeout: 30s
      retries: 3

  cache:
    container_name: cache
    image: redis:alpine
    profiles:
      - dependencies
      - full
    healthcheck:
      test: ["CMD", "redis-cli", "ping"]
      interval: 30s
      timeout: 30s
      retries: 3

volumes:
  db_data:

Essas são algumas formas de deixar seu Docker Compose um pouco mais dinâmico e inteligente.

Fonte