Tradução de http://elixir.ematia.de/trac/wiki/BehindTheScene
Debaixo dos panos
Aqui está alguma explicação detalhada no que acontece nas entranhas do Elixir. Vamos usar o nosso exemplo do tutorial:
class Movie(Entity):
using_options(tablename="movies")
title = Field(Unicode(30))
year = Field(Integer)
description = Field(Unicode)
Repare que no texto a seguir, usarei os termos entidade e classe` para referir-me a classe.
Primeiro, quando a classe é declarada, using_options é chamado e cada um desses três atributos é "interpretado" e três instâncias de Field são criadas. Como using_options é um (uma instância de) ClassMutator (um tipo de decorador de classes usando métodos), tudo o que ele faz quando é chamado pela primeira vez é guardar os argumentos e argumentos de palavra chave com que foi chamado usando um atributo especial/oculto da classe [1] [2] . Você poderia perguntar: porque não agir diretamente? Bem, pela simples razão que nesse ponto, esses mutators não conhecem sobre a classe na qual são usados. Esses campos nem sabem que tem algo a ver com uma entidade de Filme.
| [1] | em __elixir_mutators__ para aqueles que precisam saber. |
| [2] | é feito usando alguns truques com a pilha de execução. |
Metaclasse
Então, entra a metaclasse (EntityMeta. Entre outras coisas, ela:
- dá a oportunidade para que os ClassMutators atuem. Que significa que cada um dos class mutators para nossa classe serão processados. Ser processado, significa, no caso mais simples, que a função manipuladora registrada para o item é executada com os argumentos guardados[3]_. No nossos exemplo, isso irá resultar na seguinte chamada: using_options_handler(tablename="movies").
- processa cada um dos atributos de classe, procurando por instâncias da classe Property e amarrando-as à entidade. Isso simplesmente chama o método attach em casa uma dessas propriedades, e dá a elas a habilidade de conhecer a qual entidade que elas pertencem e qual atributo elas "gerenciam". Como a classe Field class é uma forma especializada (ela herda da) classe Property, nossos campos acima são incluídos nesse processamento. Ligar uma Property à sua entidade tem ainda dois efeitos adicionais: o atributo é removido da classe (para não interferir com o sistema de gerenciamento de atributos do SQLAlchemy) ae registrado na lista de objetos EntityBuilder para essa entidade. Mais sobre isso a seguir.
- se a entidade é configurada com a opção autosetup=True, os gatilhos de setup são instalados.
| [3] | Como nós frequentemente usamos handlers que fazem a mesma coisa, nós providenciamos alguns ClassMutators que fazem um pouco mais que apenas chamad o método handler. |
Fase de configuração
Então vem a fase da configuração. Quando essa fase acontece depende da sua utilização ou não do autosetup, e se você usou o autosetup, quando você disparou um dos gatilhos. O objetivo da fase de configuraço é construir a tabela e o mapeador para suas entidades. Isso é feito chamando os entity builders e também alguns métodos da entidade em si (ou melhor, seu descriptor que é apenas um objeto criado para facilitar a fase de inicialização sem adicionar muitos métodos para a entidade em si).
Agora, o que é um EntityBuilder? Citando a documentação da API:
Uma Entity builder é uma classe de objetos que podem ser adicionados em uma entidade (normalmente pelo uso de propriedades especiais ou declarações) que "constróem" essa entidade . Construir uma entidade significa adicionar colunas à sua tabela principal, criar outras tabelas, adicionar proriedades ao seu mapeador, ... Para fazer isso, um EntityBuilder deve sobrescrever o(s) método(s) correspondente(s). Isso é para garantir que diferentes operações aconteçam na ordem correta (por exemplo, garantir que a tabela esteja totalmente criada antes que o mapeador que a usa seja definido).
Por favor, olhe os métodos que EntityBuilders tem. A sequência exata de inicialização é atualmente como segue. Passos marcados com EB são feitos chamando o método correspondente [4] em todos os entity builders da entidade.
- setup_autoload_table
- create_pk_cols (EB)
- setup_relkeys (EB)
- before_table (EB)
- setup_table
- setup_reltables (EB)
- after_table (EB)
- setup_events
- setup_properties (EB)
- before_mapper (EB)
- setup_mapper
- after_mapper (EB)
- finalize (EB)
Note que a sequência exata certamente mudará em versões futuras, já que o trabalho completo será feito por entity builders no futuro. O ponto importante é que todos esses passos são feitos em ordem para todas as entidades de uma vez. Isso significa que o primeiro passo é feito para todas as entidades registradas, depois o segundo, e assim por diante.
| [4] | O nome do método no entity builder não é sempre exatamente o mesmo, mas você pegou o espírito da coisa. |
TODO
Related entities / classes lookup
- To document briefly in tutorial and/or API docs if not already
- Inverse relationships matching
- Related entities / classes lookup
- M2M table
