Rails 2: Foxy Fixtures não tem suporte a id!
Essa semana no projeto Lucidus passamos por um problema com as foxy fixtures do Rails 2.
Estávamos utilizando um modelo que possuia um autorelacionamento e outro modelo que se relacionava com o primeiro. Algo equivalente a:
class Pessoa < ActiveRecord::Base
belongs_to :pai, :class_name => 'Pessoa', :foreign_key => 'pai_id'
end
class Endereco < ActiveRecord::Base
belongs_to :pessoa
end
E precisávamos criar uma fixture de pessoa que tivesse um relacionamento para outra fixture pessoa, além de uma fixture de endereço que se relacionasse com uma de pessoa. Não sabiamos que as foxy fixtures possuiam suporte a autorelacionamento então primeiro tentamos algo como:
# pessoas.yml
pai_01:
id: 1
nome: Nome do Pai
filho_01:
id: 2
nome: Nome do Filho
pai_id: 1
# enderecos.yml
endereco_01:
pessoa: filho_01
rua: rua 1
numero: 25
Teoricamente, no carregamento das fixtures no banco, deveria fazer o apontamento correto do endereço endereco_01 preenchendo o campo pessoa_id do mesmo com o id 2, do filho_01. Mas não era isso que acontecia. Era preenchido um id aleatório no campo pessoa_id do endereco_01(se o banco possuisse a constraint de foreign key daria erro no carregamento, claro). Já estávamos achando que era um problema/bug(e é na verdade) das foxy fixtures, mas resolvi pesquisar no changelog do activerecord e descobri que não há suporte a ids nas foxy fixtures, tudo deve ser indexado somente pelos nomes e há suporte a autorelacionamento. Corrigindo então fica assim:
# pessoas.yml
pai_01:
nome: Nome do Pai
filho_01:
nome: Nome do Filho
pai: pai_01
# enderecos.yml
endereco_01:
pessoa: filho_01
rua: rua 1
numero: 25
Desse modo todos os ids são criados dinamicamente, e as fixtures se acham na hora do load no banco para a execução dos testes.
Obs: Eu não testei esse código, escrevi tudo direto no editor, pode ser que exista algum erro de sintaxe ou coisa assim.
0 comentários : 13.01.2008 10:38 AM
Invente menos problemas!
O açucar União está com uma campanha publicitária chamada Viva Momentos de União, que possui mensagens que fazem alusão a situações de prazer e bem-estar, realçando a importancia da qualidade de vida e tudo mais. Não se preocupem, não vou escrever sobre açucar!
No projeto Lucidus os nossos sachês de açucar pro café são da União e cada um vem com uma mensagem, entre elas essa que eu achei brilhante:
Invente menos problemas.
E aí isso me remete, como desenvolvedor, ao nosso velho problema de querer sempre complicar as coisas. Há um bom tempo que estudo XP, mas foi somente nos últimos meses que tive a oportunidade de ver na prática como a coisa funciona. Desde que entrei para o projeto Lucidus meus conceitos sobre como desenvolver software mudaram muito, do meu ponto de vista para melhor, claro.
XP possui como um de seus valores a simplicidade. A idéia é implementar as coisas da forma mais simples possível, sem preocupar-se com o amanhã ou com tentar prever quais funcionalidades, métodos ou funções serão necessárias no futuro. É preocupar-se apenas em resolver o problema de agora de forma simples. Isso puxa(ou o inverso) uma das práticas do XP, o design incremental.
Quando estudei engenharia de software tradicional na universidade “aprendi” que o design deveria ser sempre feito antes da implementação. Então deveria-se planejar(o sistema, as classes, os patterns, a base de dados, os relacionamentos, etc) numa tentativa de prever o rumo que o projeto iria levar. Felizmente aprendi cedo de que isso na teoria é muito bonito, mas na prática não funciona. Quer queiram ou não, os projetos de software sempre sofrem mudanças na hora da implementação. Mudanças essas que podem ser drásticas a ponto de toda documentação/projeto que foi escrito não servir mais para nada, por não refletir a realidade do projeto.
Quando em XP dizemos que trabalhamos com design incremental do software, não estamos dizendo que não usamos patterns… Isso apenas quer dizer que decidimos que patterns utilizar na hora em que de fato precisarmos dele. O uso contínuo da refatoração nos leva aos patterns.
Há alguns anos atrás eu trabalhava(leia-se ganhava dinheiro) apenas com Java e, por coincidência ou não, muitas das pessoas com que trabalhei e empresas por onde passei possuiam essa mesma cabeça da engenharia de software tradicional e passavam meses projetando e montando o ambiente de trabalho antes de que qualquer linha de código útil fosse escrita.
Felizmente, mais uma vez, há 2 anos eu descobri o Ruby e o Rails. Descobri que as pessoas que trabalham com Ruby e Rails seguem fielmente a linha da simplicidade, dos princípios DRY e KISS. Descobri que Rails se encaixa como uma luva no XP. Então a frase do dia é:
Invente menos problemas. Use Rails!
2 comentários : 12.01.2008 03:55 PM
