ActiveRecord: table_name overrides
O curso mostra como o ActiveRecord liga uma classe de model à tabela do banco e como self.table_name sobrescreve essa ligação. Começa pela convenção de nomes do Rails e pelo método table_name_prefix que os módulos de namespace deste app definem. Depois explica por que o app separa nomes de tabela dos namespaces Ruby. Em seguida vêm três tipos de sobrescrita: uma que tira um prefixo, uma que não muda nada e uma que acrescenta precisão. As últimas aulas tratam do que table_name não afeta, como chaves estrangeiras e migrations.
O que você vai aprender
- ✓Como o Rails chega ao nome da tabela tirando o módulo, passando para snake_case e pondo no plural
- ✓Como o table_name_prefix de um módulo define o nome padrão das tabelas dos seus models
- ✓Por que os nomes de tabela ficam separados dos namespaces Ruby
- ✓Três trabalhos de self.table_name: tirar um prefixo, repetir a convenção e acrescentar precisão
- ✓Por que chaves estrangeiras e migrations não dependem do table_name de um model
- ✓Como um table_name errado falha com PG::UndefinedTable
A convenção de nomes do Rails, e onde este app a quebra
Todo model que estes cursos tocaram, como Catalog::Course, Enrollment::Enrollment e Identity::User, encontra a própria tabela sem ninguém escrever código de mapeamento, na maior parte das vezes. A regra do Rails é pegar o nome da classe, tirar o módulo (descartar qualquer prefixo Module::), passar…
Ler a aula completa grátis →Currículo
7 aulasA convenção de nomes do Rails, e onde este app a quebra
Como o Rails transforma o nome de uma classe em nome de tabela, e por que Catalog::Course precisa de self.table_name.
table_name_prefix: o padrão do namespace
O método table_name_prefix nos módulos de namespace, e como Community::Comment resolve para community_comments por meio dele.
Separando nomes de tabela da estrutura de domínio de propósito
Por que este app separa nomes de tabela dos namespaces, para que mover uma classe nunca exija renomear tabela.
Quando a sobrescrita não muda nada
Identity não tem prefixo, então User dispensa sobrescrita e a sobrescrita de UserPreference não muda nada.
Quando a sobrescrita muda algo de propósito
Identity::Authentication sobrescreve a tabela para identity_authentications, acrescentando uma precisão que a convenção simples nunca daria.
O que table_name não afeta
Chaves estrangeiras vêm do nome da associação, um table_name errado levanta PG::UndefinedTable e migrations não leem models.
Juntando tudo: três sobrescritas, um mecanismo
Uma comparação de três sobrescritas com o mesmo mecanismo, e como saber qual trabalho cada uma faz.