Forum: Rails-ES Cambiar tipo de columna

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Jose vicente R. (Guest)
on 2008-12-17 21:17
Hola, he estado mirando por la web y no he encontrado nada sobre cambiar
el tipo de las columnas. hay alguna forma de que una columna pasa por
ejemplo de string a integerusando el migrate?
Juan P. (Guest)
on 2008-12-17 21:26
(Received via mailing list)
Esta en la doc de rails, busca en ActiveRecord::Migration

2008/12/17 Jose vicente Ribera pellicer
<removed_email_address@domain.invalid>
Jose vicente R. (Guest)
on 2008-12-17 21:26
Juan P. wrote:
> Esta en la doc de rails, busca en ActiveRecord::Migration
>
> 2008/12/17 Jose vicente Ribera pellicer
> <removed_email_address@domain.invalid>
ok
Jose vicente R. (Guest)
on 2008-12-17 21:43
Quiero cambiar la columna send_mail  de la tabla tickets de string a
integer.

En consola:
ruby script/generate migration change_column(tickets, send_mail,
integer)

En la carpeta de las migraciones se genera:

class ChangeColumn(tickets,sendMail,integer) < ActiveRecord::Migration
  def self.up
  end

  def self.down
  end
end

Pero al ejecutar rake db:migrate me da el siguiente error
Illegal name for migration file: db/migrate//027_change_column(tickets,
send_mail,intger).rb

(only lower case letters,numbers,and '_'allowed)


Me esta diciendo que uso algun caracter extraño no?? Pero como se ve en
el mensaje no hay nada raro
Isaac Feliu Pérez (Guest)
on 2008-12-17 21:52
(Received via mailing list)
Jose,

el comando script/generate migration espera que le pases un nombre que
describa el migration, para luego editar el fichero con tu editor
preferido y le pongas "contenido".

Tu le has puesto un nombre algo raro (realmente querias que fuera el
contenido). Si te fijas en el fichero que te ha generado, aparte del
nombre, que es más raro que un perro verde... (¿¿ un fichero llamado
"noseque(pimpam, pum).rb" ??), te genera también una clase incorrecta,
fijate en la definición de la clase, no te parece raro ver parámetros
en un class NombreClase?

ejecuta script/generate migration change_column_in_table, que te
generará un fichero 027_change_column_in_table.rb y una clase del tipo

class ChangeColumnInTable < ActiveRecord::Migration
   def self.up
   end

   def self.down
   end
end

entonces aplicas tu change_column(loquesea.... en los métodes de clase
up y down.

Espero haberme explicado!

Saludos,
--
Isaac Feliu
Jose vicente R. (Guest)
on 2008-12-17 21:53
Al final he hecho el cambio con el plugin de firefox SQLite manager.

Un saludo
Manuel González Noriega (Guest)
on 2008-12-17 23:28
(Received via mailing list)
2008/12/17 Jose vicente Ribera pellicer
<removed_email_address@domain.invalid>

> Al final he hecho el cambio con el plugin de firefox SQLite manager.
>
>
Pues ... no deberías ¿Has entendido lo que te han explicado y qué era lo
que
hacías mal?
Jaime I. (Guest)
on 2008-12-18 01:41
(Received via mailing list)
On Wed, Dec 17, 2008 at 10:28 PM, Manuel González Noriega
<removed_email_address@domain.invalid> wrote:
> 2008/12/17 Jose vicente Ribera pellicer <removed_email_address@domain.invalid>
>>
>> Al final he hecho el cambio con el plugin de firefox SQLite manager.
>>
>
> Pues ... no deberías ¿Has entendido lo que te han explicado y qué era lo que
> hacías mal?

Ya se dará cuenta cuando lo ponga en producción :)

--
Jaime I.
http://jaimeiniesta.com
http://www.workingwithrails.com/person/6722-jaime-iniesta
Andrés G. (Guest)
on 2008-12-18 10:36
(Received via mailing list)
La verdad es que no se porque a la gente le cuesta tanto entender las
indicaciones (yo no tengo mucha idea) pero con lo que le ha dicho
Isaac y Mr. google este problema se solventa en 2 min.

Jose vicente : "Mirate otra vez el hilo y aprenderas algo que ya te
vale para el futuro"

El día 18 de diciembre de 2008 0:41, Jaime I.
<removed_email_address@domain.invalid>
escribió:> On Wed, Dec 17, 2008 at 10:28 PM, Manuel González Noriega
Jaime I. (Guest)
on 2008-12-18 11:33
(Received via mailing list)
2008/12/18 Andrés gutiérrez <removed_email_address@domain.invalid>:
> La verdad es que no se porque a la gente le cuesta tanto entender las
> indicaciones (yo no tengo mucha idea) pero con lo que le ha dicho
> Isaac y Mr. google este problema se solventa en 2 min.

¿Verdad? Y lo a gusto y lo tranquilo que te quedas cuando aprendes
cómo funciona algo y no te limitas a cachipegar códigos sin saber qué
es lo que hacen realmente...

--
Jaime I.
http://jaimeiniesta.com
http://www.workingwithrails.com/person/6722-jaime-iniesta
Andrés G. (Guest)
on 2008-12-18 11:36
(Received via mailing list)
>>¿Verdad? Y lo a gusto y lo tranquilo que te quedas cuando aprendes
>>cómo funciona algo y no te limitas a cachipegar códigos sin saber qué
>>es lo que hacen realmente...

+1. Ahi estoy yo, en el camino :-)

Un saludo

2008/12/18 Jaime I. <removed_email_address@domain.invalid>:
Jose vicente R. (Guest)
on 2008-12-18 17:21
>>> Al final he hecho el cambio con el plugin de firefox SQLite manager.
>>>
>>
>> Pues ... no deber�as �Has entendido lo que te han explicado y qu� era lo que
>> hac�as mal?
>
> Ya se dar� cuenta cuando lo ponga en producci�n :)
>



Haber, no soy partidario de hacer los cambios con un gestor de bases de
datos. Me gusta dejar constancia de ello al añadir columnas y demas
cambios, asi voy viendo como mi proyecto va crecienado en la carpeta de
las migraciones  y eso me ayuda a comprenderlo mejor. Pero en este caso
como fue un error (deberia haber sido integer desde un principio) y la
contestacion de como resolverlo se posteo mientras escribia la mia lo
hice con el gestor. Elimine la columna que no queria y le añadi la misma
solo que con el tipo que me interesaba.

Tan grabe es hacer cosas asi? ya no lo digo por dominar mas o menos la
gestion de la base de datos desde consola (que reitero me parece
necesario saber controlar), me refiero a los comentarios tipo "ya se
dara cuenta cuendo lo ponga en produccion", que pasa? que no va a
funcionar o que?


Y sobretodo, agradezco todo tipo de ayuda, de hecho sin este foro no
llevaria el proyecto como lo llevo. Por ello no quiero que se interprete
mi metodo de resolverlo como un "ya le vale, la gente le dice como tiene
que hacerlo y se va de cabeza al gestor", para nada, pero cuando postee
mi solucion no me pare a leer las respuestas ya que antes de postear no
existia ninguna mas.


Un salydo
Andrés G. (Guest)
on 2008-12-18 17:41
(Received via mailing list)
Por mi parte te pido disculpas, cero que te he juzgado sin saber todo
lo que has explicado (a la ligera) y no he aportado nada. Así que
perdón. se nota que estas entusiasmado, y yo no quisiera que mis
comentarios te sirviesen para no seguir entrando a esta lista (que es
la ostia). Ademas me he añadido a lo que ha dicho Jaime sin saber por
que lo decía (soy un gilipoll...). Por cierto Jaime ¿Por qué lo has
dicho? en producción es basico??? es por otro motivo???

Un saludo a todos y de nuevo disculpas a Jose vicente por prejuzgarle

El día 18 de diciembre de 2008 16:21, Jose vicente Ribera pellicer
<removed_email_address@domain.invalid> escribió:
Fernando G. (Guest)
on 2008-12-18 17:45
(Received via mailing list)
El día 18 de diciembre de 2008 16:41, Andrés gutiérrez
<removed_email_address@domain.invalid>
escribió:> Por cierto Jaime ¿Por qué lo has
> dicho? en producción es basico??? es por otro motivo???

Me imagino que Jaime se refería a que sí cambias algo accediendo
directamente a tu BD de desarrollo sin arreglar las migraciones cuando
vayas a producción no podrás confiar en que las migraciones te vayan a
crear una BD bien.

f.
Jaime I. (Guest)
on 2008-12-18 17:49
(Received via mailing list)
2008/12/18 Fernando G. <removed_email_address@domain.invalid>:
> El día 18 de diciembre de 2008 16:41, Andrés gutiérrez
> <removed_email_address@domain.invalid> escribió:
>> Por cierto Jaime ¿Por qué lo has
>> dicho? en producción es basico??? es por otro motivo???
>
> Me imagino que Jaime se refería a que sí cambias algo accediendo
> directamente a tu BD de desarrollo sin arreglar las migraciones cuando
> vayas a producción no podrás confiar en que las migraciones te vayan a
> crear una BD bien.

Eso mismo. Por lo poco que se explicaba en el mail, parecía que iba a
hacer cambios en la estructura de las tablas sin usar migraciones, no
que fuera una modificación para corregir alguna cosa (que de todos
modos no sé cómo llegó a tener un tipo incorrecto de columnas, si no
se ha usado nada más que migraciones, será que ya le metiste mano a la
BD directamente?).

Por eso decía lo de "darse cuenta al pasar a producción". Porque en
ese caso faltaría ese cambio al no estar en migraciones, y
tambiéntendría que hacerlo a pata.

--
Jaime I.
http://jaimeiniesta.com
http://www.workingwithrails.com/person/6722-jaime-iniesta
Jose vicente R. (Guest)
on 2008-12-18 18:37
Exactamente, antes de usarla ya estaba mal parida, vamos que tenia que
ser integer pero me despiste al hacer el scaffold y cuando la quise usar
vi que era string.

Y tranquilos que tampoco es para pedir disculpas, entiendo que visto
como lo visteis vosotros pudierais pensar que pidiera ayuda para luego
tirarme por lo facil.

Lo dicho un placer estar aprendiendo con y de vosotros.En el fondo las
referencias que haga en el proyecto se centran 90% en el Agile Web
Development with rails y en este foro, asi que no me puedo quejar...eso
si, al menos prometo publicidad gratis en la Politecnica de Valencia
durante el discurso ;)


Un saludo a todos...hasta la proxima!!
Andrés G. (Guest)
on 2008-12-18 18:46
(Received via mailing list)
Gracias por la aclaración Jaime y Fernando. Nunca he puesto una App en
producción y eso se nota

Un saludo

El día 18 de diciembre de 2008 17:37, Jose vicente Ribera pellicer
<removed_email_address@domain.invalid>
escribió:> Exactamente, antes de usarla ya estaba mal parida, vamos que tenia 
que
Jaime I. (Guest)
on 2008-12-18 18:48
(Received via mailing list)
2008/12/18 Jose vicente Ribera pellicer
<removed_email_address@domain.invalid>:
> Development with rails y en este foro, asi que no me puedo quejar...eso
> si, al menos prometo publicidad gratis en la Politecnica de Valencia
> durante el discurso ;)
>
>
> Un saludo a todos...hasta la proxima!!

A seguir bien! Un placer!

--
Jaime I.
http://jaimeiniesta.com
http://www.workingwithrails.com/person/6722-jaime-iniesta
Jesús N. (Guest)
on 2008-12-19 11:16
(Received via mailing list)
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 ;).

Por lo que veo, has creado una columna con el tipo equivocado, y querías
corregir el tipo, esto estaba pasando en desarrollo y nunca había subido
a
producción, ¿no es así?

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 ;).

Por otro lado si te preocupan tus datos... bueno, estás en desarrollo,
no
debería ser un problema grave :).

Me pregunto, ¿no es mejor así? En mi opinión todo lo que se hace con
migrations, debería arreglarse con ellas.

Un saludo,

2008/12/18 Jaime I. <removed_email_address@domain.invalid>

> > Lo dicho un placer estar aprendiendo con y de vosotros.En el fondo las
> --
> Jaime I.
> http://jaimeiniesta.com
> http://www.workingwithrails.com/person/6722-jaime-iniesta
> _______________________________________________
> Ror-es mailing list
> removed_email_address@domain.invalid
> http://lists.simplelogica.net/mailman/listinfo/ror-es
>



--
Jesús Navarrete

http://www.jenaiz.com
Jaime I. (Guest)
on 2008-12-19 12:48
(Received via mailing list)
2008/12/19 Jesús Navarrete <removed_email_address@domain.invalid>
>
> 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 ;).
>
> Por lo que veo, has creado una columna con el tipo equivocado, y querías corregir el 
tipo, esto estaba pasando en desarrollo y nunca había subido a producción, ¿no es así?
>
> 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 ;).

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:

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

> Por otro lado si te preocupan tus datos... bueno, estás en desarrollo, no debería ser un 
problema grave :).
>
> Me pregunto, ¿no es mejor así? En mi opinión todo lo que se hace con migrations, debería 
arreglarse con ellas.

Sip, pero sobre todo la idea es que, partiendo desde cero, se pueda
crear toda la estructura de tablas sin usar nada más que las
migraciones, sin meter mano a la base de datos directamente, claro.

Besos a todas,

--
Jaime I.
http://jaimeiniesta.com
http://www.workingwithrails.com/person/6722-jaime-iniesta
javier ramirez (Guest)
on 2008-12-19 13:01
(Received via mailing list)
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
Jaime I. (Guest)
on 2008-12-19 16:11
(Received via mailing list)
On Fri, Dec 19, 2008 at 12:01 PM, javier ramirez 
<removed_email_address@domain.invalid>
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" :P

--
Jaime I.
http://jaimeiniesta.com
http://www.workingwithrails.com/person/6722-jaime-iniesta
Jesús N. (Guest)
on 2008-12-19 17:42
(Received via mailing list)
On 12/19/08, Jaime I. <removed_email_address@domain.invalid> 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

http://www.jenaiz.com
Jose vicente R. (Guest)
on 2008-12-19 19:02
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?
Jesús N. (Guest)
on 2008-12-19 19:36
(Received via mailing list)
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 ;) 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
<removed_email_address@domain.invalid>

> > migrations
> >
> removed_email_address@domain.invalid
> http://lists.simplelogica.net/mailman/listinfo/ror-es
>



--
Jesús Navarrete

http://www.jenaiz.com
Jose vicente R. (Guest)
on 2008-12-19 20:17
> Y no deberías haber metido esos 100 clientes a mano!! (espero que no lo
> hayas hecho ;) 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
Jaime I. (Guest)
on 2008-12-19 20:46
(Received via mailing list)
2008/12/19 Jose vicente Ribera pellicer
<removed_email_address@domain.invalid>:
> 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
Jose vicente R. (Guest)
on 2008-12-19 21:04
Jaime I. wrote:
> 2008/12/19 Jose vicente Ribera pellicer
> <removed_email_address@domain.invalid>:
>> 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.
Jaime I. (Guest)
on 2008-12-19 22:30
(Received via mailing list)
2008/12/19 Jose vicente Ribera pellicer
<removed_email_address@domain.invalid>:
>>
> 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 :P

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
This topic is locked and can not be replied to.