Cambiar tipo de columna

Hola,

De hecho yo tengo la manía de comprobar cada vez que hago una
migración, para ver si la he escrito bien palante y patrás:

muy buena práctica!!

rake db:migrate && rake db:rollback && rake db:migrate

desde hace unas versiones de rails ya puedes hacer

rabe db:migrate:redo

que es lo mismo que un rollback + migrate

saludos,

j


javier ramírez

…i do ruby on rails development in madrid, spain, at
http://www.aspgems.com
…you can find out more about me on http://formatinternet.wordpress.com
and http://workingwithrails.com/person/5987-javier-ramirez

On Fri, Dec 19, 2008 at 12:01 PM, javier ramirez [email protected]
wrote:

desde hace unas versiones de rails ya puedes hacer

rabe db:migrate:redo

que es lo mismo que un rollback + migrate

Mola! Pues entonces
rake db:migrate && rake db:migrate:redo

Y de aquí viene la canción esa de “mígrate y vuélvete a migrar, que
los migraditos no saben bailar” :stuck_out_tongue:


Jaime I.
http://jaimeiniesta.com
http://www.workingwithrails.com/person/6722-jaime-iniesta

Jesús Navarrete wrote:

Bueno, con los datos actuales, me gustaría añadir algo; al margen de
todo lo
que parece haberse montado por no haberlo contado todo Jose Vicente ;).

Pues yo insistiría en usar sólo migrations para corregir estas cosas. No
sé
si conoces, por lo que lo cuento, puedes correr las migrations hacia
delante
y hacia atrás, incluso puedes hacer un redo del último “grupo” de
migrations
que lanzaste, por lo que debieras corregir la migration, como ya creo
que
has hecho y deshacer y volver a hacer. O deshacer, corregir y hacer,
depende
de la migration que tengas. Ten en cuenta que las migrations no sólo van
hacia adelante, sino que también pueden y deben retroceder, así si tu
marcha
atrás funciona comprobarás que tus self.down funcionan perfectamente y
no
los has ido dejando vacíos ;).

Ok, pero al tirar las migraciones hacia atras, las tablas las resetea
no?
Imaginemos que tengo una tabla en la que he introducido 100 clientes,
tocaria volverlos a meter uno a uno no?

On 12/19/08, Jaime I. [email protected] wrote:

desde hace unas versiones de rails ya puedes hacer

rabe db:migrate:redo

que es lo mismo que un rollback + migrate

Mola! Pues entonces
rake db:migrate && rake db:migrate:redo

Menos mal que Javier lo ha puntualizado :P, a eso me refería con hacer
el
redo… pero abreviando y sin dar el comando XD.

saludos.


Jesús Navarrete

Y no deberías haber metido esos 100 clientes a mano!! (espero que no lo
hayas hecho :wink: deberías haber automatizado un proceso similar, hay
numerosas
opciones para ello. Por eso te decía que hechar para atrás esa migración
no
debiera ser el problema, siempre hablo de desarrollo.

Saludos,

A decir verdad meti 3 a mano… y viendo el tiempo que requeria pense
que mejor preocuparse de ello mas tarde, que seguro descubria una forma
mas sencilla de hacerlo…y mira tu por donde la hay ;).

Ok, en el schema me he anotado el fallo como un comentario, antes de
pasar a produccion lo corregire,tirare para atras en migration,
actualizare y hare la modificacion.

Otra duda que me surge…esta claro que con migraciones puedo crear una
base de datos, pero no hay opcion para calcar directamente una base de
datos, un copy/paste literal, eso ayudaria a solucionar este
tipo de problemas y digo yo (desde mi ignorancia) que una cosa que
parece tan basica sera sencillisima de hacer no?.

Un saludo

Te comentaba que estando en desarrollo no debería ser un problema borrar
tus
datos, porque básicamente son de prueba.

Y no deberías haber metido esos 100 clientes a mano!! (espero que no lo
hayas hecho :wink: deberías haber automatizado un proceso similar, hay
numerosas
opciones para ello. Por eso te decía que hechar para atrás esa migración
no
debiera ser el problema, siempre hablo de desarrollo.

Saludos,

2008/12/19 Jose vicente Ribera pellicer
[email protected]

migrations

[email protected]
http://lists.simplelogica.net/mailman/listinfo/ror-es


Jesús Navarrete

2008/12/19 Jose vicente Ribera pellicer
[email protected]:

que mejor preocuparse de ello mas tarde, que seguro descubria una forma
tipo de problemas y digo yo (desde mi ignorancia) que una cosa que
parece tan basica sera sencillisima de hacer no?.

Supongo que te refieres a los ficheros db/development_structure.sql y
db/schema.rb que tienen un “resumen” de la estructura de la base de
datos según el estado actual tras aplicar las migraciones…

Pero todo lo deberías pensar en base a las migraciones, es más ordenado
así.

Jaime I.
http://jaimeiniesta.com
http://www.workingwithrails.com/person/6722-jaime-iniesta

Jaime I. wrote:

2008/12/19 Jose vicente Ribera pellicer
[email protected]:

que mejor preocuparse de ello mas tarde, que seguro descubria una forma
tipo de problemas y digo yo (desde mi ignorancia) que una cosa que
parece tan basica sera sencillisima de hacer no?.

Supongo que te refieres a los ficheros db/development_structure.sql y
db/schema.rb que tienen un “resumen” de la estructura de la base de
datos seg�n el estado actual tras aplicar las migraciones…

Pero todo lo deber�as pensar en base a las migraciones, es m�s ordenado
as�.

Lo quiero hacer en base a las migraciones por que para algo nos gusta el
tema, pero quiero tener la seguridad de que existe una via alternativa.
Imaginemos que en un futuro nos toca trabajar con una aplicacion que no
es nuestra, por lo tanto no tenemos certeza de que quien la diseño
siguiera un diseño “limpio” basado en migraciones. Si copio la base de
datos y la carpeta de schema trabajaria perfectamente,eso si, otro gallo
cantaria si quisiera trastear con la base de datos.

2008/12/19 Jose vicente Ribera pellicer
[email protected]:

datos y la carpeta de schema trabajaria perfectamente,eso si, otro gallo
cantaria si quisiera trastear con la base de datos.

Yo creo que a estas alturas se debe asumir que todo el mundo trabaja
con migraciones. Puestos a asumir cosas, podrías asumir que los
modelos los guarda en /app/mis_modelos y los controladores en
/app/controleitors, y que en general las convenciones se las pasa por
el forro :stuck_out_tongue:

Quiero decir, que si te pasan algo sin migraciones, apaga y vámonos!
No son una opción, es la manera de trabajar en rails.


Jaime I.
http://jaimeiniesta.com
http://www.workingwithrails.com/person/6722-jaime-iniesta