2009/4/17 Mariano Simone <[email protected]>: > 2009/4/8 Nicolás Sanguinetti <[email protected]> >> >> InnoDB es el engine por defecto. >> >> Sobre los datos, no los ingreses en migraciones. Dejame repetir eso: >> >> NO INGRESES DATOS EN MIGRACIONES >> >> :) >> >> Definí un rake task db:seed o algo así que cree los objetos adecuados, >> y mantené ese task con todos los datos que tiene que tener la db en su >> estado "limpio". Las migraciones son frágiles y *seguro* se te van a >> romper cuando llegues a tener cosas como 100 o 150 migraciones en un >> proyecto. >> >> Después tu proceso de setup de tu aplicación va a ser algo así: >> * crear config/database.yml >> * rake db:schema:load >> * rake db:seed >> >> Nosotros usamos http://github.com/technoweenie/app-bootstrap, que >> funciona relativamente bien para estandarizar el proceso de >> inicialización de tu app. >> >> -foca > > Avanzo en esta dirección y me surge una duda: > > Uno de los casos particulares de "datos maestros" que tengo es proveedores > de celulares... Algo que veo a través de las migrations que se hicieron > hasta ahora, es que se dieron de baja a algunos y se agregaron otros. > > ¿Cuál sería la forma "correcta" de manejar esto? No me queda claro cómo > encuadra hacer las altas/bajas en una base existente con mantener el task de > seeds
Para mí, la forma correcta es: 1. crear una migration donde das de baja o de alta los registros que necesites. Esto le servirá al sistema que ya tenés en producción. 2. además, agregar o quitar de los datos del seed los registros que estás eliminando/agregando desde la migration. Esto te servirá para seguir usándolo como seed en tus tests y también por si tenés que hacer una instalación de cero, sin depender de las migrations. Eso es todo. Diego _______________________________________________ Ruby mailing list [email protected] http://lista.rubyargentina.com.ar/listinfo.cgi/ruby-rubyargentina.com.ar
