Rails 3 migrations: boolean (mysql vs postgreSQL)

Estoy tratando de agregar una opción "adhesiva" en los temas de mi foro. Este es el aspecto de mi migración comoRails 3 migrations: boolean (mysql vs postgreSQL)

def self.up 
    add_column :topics, :sticky, :boolean, :null => false, :default => false 
    end 

    def self.down 
    remove_column :topics, :sticky 
    end

Esto funciona perfecto localmente en MySQL, pero cuando presiono los cambios en heroku (que utiliza PostgreSQL), esto es lo que me pasa cuando se utiliza la consola

>> t.sticky 
=> "f" 
>> t.sticky.class 
=> String 
>> t.sticky = true 
=> true 
>> t.sticky.class 
=> TrueClass

¿Por qué el valor predeterminado de esta propiedad es una cadena?

Edit: Y si guardo el objeto, no cambia la propiedad adhesiva, es decir, sigue siendo "f".

Fuente

2011-05-24 Marjan

No veo ese comportamiento en mi Postgres local o Heroku's. Estoy usando Rails 3.0.7 y la versión 0.11.0 de la gema pg. Por cierto, recomiendo usar Postgres localmente en su máquina de desarrollo. Hay una serie de diferencias entre Postgres y mysql (group by, case-sensitivity, etc.), e incluso si esto no es (o no debería ser) uno de ellos, eventualmente se topará con algo. –

En psql, los booleanos se muestran como t o f. Según el controlador de base de datos, estos se convierten en booleanos o se dejan en su representación de cadena.

El controlador PDO en PHP hace lo mismo. (O solía, de todos modos ... Recuerdo vagamente que ya no lo hace en su última versión.)

Fuente

2011-05-24 10:37:18

Ya veo. ¿Alguna idea de por qué los rieles no los convierten automáticamente en valores booleanos? – Marjan

Eso sería un buen informe de pregunta/error para los desarrolladores de RoR. :-) –

A menos que encuentre un error en RoR o en el controlador de la base de datos, como sugiere Denis, puede definir (anular) acceso de lectura como:

def sticky 
    ! [false, nil, 'f'].include?(self[:sticky]) 
end

Esto convertirá los valores conocidos 'falsos' a los booleanos ruby reales.

Recuerdo que había al menos dos gemas para conectarse a las bases de datos PostgreSQL. ¿Quizás puedas usar el otro?

¿Y está seguro de que la columna en la base de datos no está definida como Cadena? Sé que en tu migración es booleano, pero ¿tal vez algo salió mal?

Fuente

2011-05-24 11:50:52 Arsen7

Ha pasado mucho tiempo desde que utilicé el driver Ruby PostgreSQL, pero parece que se devolvieron VERDADERO y FALSO como las cadenas 't' y 'f', respectivamente. Irritante como el infierno ya que el enlace PostgreSQL de los demás idiomas los correlaciona correctamente con su tipo de datos booleanos nativos. Acabo de mirar https://bitbucket.org/ged/ruby-pg/src/b5361e087db3/ext/pg.c y no parece que el estado del controlador Ruby haya cambiado ninguno. El OID de Pg para BOOLOID debe verificarse y debe devolver un Qtrue o Qfalse. – Sean

Estoy usando ruby-postgres (0.7.9.20080128) y mis modelos tienen booleanos donde deberían tener. Tal vez en mi caso sea por Rails 1.2.6. Old gem + old Rails = ¿éxito? ;-) – Arsen7

Podría ser. También me siento completamente cómodo con estar equivocado (¡y me alegraría que se demuestre que estaba equivocado!), Pero no vi un mapa de tipo entre el bool oid de PostgreSQL y el tipo de bool Ruby en el controlador nativo ruby-pg (también tomé un vistazo de 2 minutos). Estoy adivinando pero estoy asumiendo que algo más en Rails está haciendo la conversión. – Sean

No estoy seguro de cuál fue el problema, pero acabo de retrotraer la migración y ejecutarla de nuevo, y funcionó esta vez. Solo pongo esto aquí en caso de que alguien más encuentre un problema similar.

Gracias por su ayuda chicos.

Fuente

2011-05-26 09:37:11 Marjan

Entonces, ¿podría ser que la columna se haya creado con un tipo incorrecto? – Arsen7

Muy posible, aunque no estoy seguro de por qué. No cambié nada, simplemente retrocedí un paso y ejecuté la migración nuevamente. – Marjan

Rails 3 migrations: boolean (mysql vs postgreSQL)

Respuesta

Cuestiones relacionadas