Cambiar tipo de columna

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?

Esta en la doc de rails, busca en ActiveRecord::Migration

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

Juan P. wrote:

Esta en la doc de rails, busca en ActiveRecord::Migration

2008/12/17 Jose vicente Ribera pellicer
[email protected]
ok

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

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

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

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?

Al final he hecho el cambio con el plugin de firefox SQLite manager.

Un saludo

On Wed, Dec 17, 2008 at 10:28 PM, Manuel González Noriega
[email protected] wrote:

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

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 :slight_smile:


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

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.
[email protected]
escribió:> On Wed, Dec 17, 2008 at 10:28 PM, Manuel González Noriega

2008/12/18 Andrés gutiérrez [email protected]:

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

¿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 :slight_smile:

Un saludo

2008/12/18 Jaime I. [email protected]:

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 :slight_smile:

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

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
[email protected] escribió:

2008/12/18 Fernando G. [email protected]:

El día 18 de diciembre de 2008 16:41, Andrés gutiérrez
[email protected] 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

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 :wink:

Un saludo a todos…hasta la proxima!!

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
[email protected]
escribió:> Exactamente, antes de usarla ya estaba mal parida, vamos que tenia que

El día 18 de diciembre de 2008 16:41, Andrés gutiérrez
[email protected]
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.

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

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 :wink:

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

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. [email protected]

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
[email protected]
http://lists.simplelogica.net/mailman/listinfo/ror-es


Jesús Navarrete

2008/12/19 Jesús Navarrete [email protected]

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