En ocasiones nos encontramos con que te instalas algo que siempre ha funcionado bien pero que cuando le cambias un poco el entorno, le tiemblan las canillas.
Por ejemplo, para una nueva aplicación instalamos l10n-simplified para menejar los mensajes de la aplicación porque siempre ha funcionado. Y todo va bien, correcto, sin complicacines. Pero me llevo la aplicación a su entorno real, corriendo en un servidor Windows y atacando SQL Server 2005 a través de un conector ODBC y me encuentro con que algo o alguien ejecuta constantemente
SET NAMES 'UTF8'
contra la base de datos y ésta responde que va a ser que no.
Jodo¡ En un mundo sin sorpresas, la primera en la frente. Rebuscando y con ayuda de Javi encontramos que en localization_simplified.rb es donde se ejecuta esta sentencia. Después de blasfemar leemos el comentario
# Currently this modifies MySQL. Please add other databases you find necessary
que por una parte me hace pensar en todas las librerías que uso sin molestarme en mirar qué tienen y por otra en que quizás un plugin no deba asumir nada respecto a qué base de datos se utiliza.
En fin, solucionado. Pero hay objetos que no se borran, casualmente todos los que están configurados como acts_as_list.
Vuelvo a blasfemar (parezco Gurb). Y veo que de nuevo alguien o algo está poniendo position = NULL en el registro a borrar justo antes de destruirlo para siempre. Tengo por costumbre poner los campos position como not NULL para las tablas que contienen registros configurados como acts_as_list. Porque si son una lista el campo siempre debe contener un valor.
Y en otro orden de cosas, para qué se pone a NULL? Para avisarle de que vas a borrarlo? Los registros, hasta la fecha, no tienen sentimientos. No hay que avisarles de nada. Se crean, se borran, se modifican... y punto¡¡¡
Y porqué MySql traga con ello y SQL Server no? Pues no lo sé y la verdad, después de todo qué más me da? Si yo lo que quiero es irme a comer a mi casa¡¡¡ Comento la línea enferma y listo.
Salud y rocanrol¡
Suscribirse a:
Enviar comentarios (Atom)
1 comentario:
Gotcha! El cacho ese del plugin parece ahí algo como a medias. Además creo como tú que el plugin hoy en día no tiene por qué poner la conexión a UTF-8 por tí, eso es responsabilidad de uno en database.yml. Parece código pensado para versiones antiguas ("antiguas" en la dimensión Rails del espacio-tiempo).
En el comentario dice también que no se necesita para Rails 1.2 o superior y en su última versión de enero de este año ya no lo hace: la linea con el before_filter está comentada, aunque sigue definiendo un método configure_charsets() en AC::Base que nadie usa y poluciona tu espacio de nombres sin justificación clara.
En cuanto a acts_as_list creo que el tema está más peliagudo. Resulta que el plugin está todo escrito bajo la asumción que un registro no necesariamente vive en una lista. Tiene un método in_list? que se mira si position es NULL y la mayoría de los métodos empiezan diciendo "no hagas nada salvo in_list?".
Esas líneas vienen de este parche y la verdad es que no entiendo tampoco muy bien por qué pone el position a NULL. Pero pienso que a lo mejor es debido al hecho de que un plugin no puede asumir que un destroy va a borrar el registro (piensa en acts_as_paranid por ejemplo), y todo lo que puede hacer es asegurarse que en cuanto a él respecta el registro no va a ser considerado in_list? en adelante.
Publicar un comentario