Shiny happy people coding

Codons avec le sourire

Travailler avec rails fait trouver des bugs

| Comments

Alors que j’ai commencé à travailler professionnelement parlant avec Rails depuis mon départ de CapGemini et mon arrivée à JTEK. En une semaine et demi, je constate 1 bug sur rails 2.1, un bug sur Edge et un comportement ajouté en Rails 2.1 qui disparaitra en Rails 2.2 (déjà disparu sur Edge)

#has_one demande la validation de sa liaison

Durant la migration de l’application développé au sein de Jtek de Rails 1.2 à 2.1, j’ai constaté que les éléments #has_one sont désormais validé durant la validation du parent. En effet, ce comportement n’était pas présent dans les versions antérieurs à Rails 2.1. Par contre, la validation du #has_many est quand à elle effectuée depuis plusieurs version de Rails.

Par contre après une lecture du code de Rails edge, actuellement, ce comportement disparaitra complétement en Rails 2.2. En effet, une option :validate a été ajouté au méthode #has_many, #has_and_belongs_to_many et #has_one. J’ai parlé de ce comportement dans une news Vivre avec Rails.

Pour palier ce problème, j’ai créé un petit plugin rails qui permet de couper la validation sur le #has_one. Vous pouvez trouver les sources sur le github de JTek.

Bug de logger dans le Runner de Rails-2.1

Sur ce point j’ai reporté un bug sur le lighthouse de Rails. En effet, j’ai constaté que si on utilisait le logger par défaut de Rails, et qu’on réalisait un log dans le code executé par script/runner il ne se retrouvait pas loggé dans le fichier production.log en mode production. Par contre en mode développement, tout se passait bien. En fait, le problème vient du nouveau Logger par défaut de rails qui est une surcouche au Logger de Ruby. Ainsi, il contient un buffer qui est flushé régulièrement. Mais en fait en mode production, le flush est désactivé. On peux ainsi retrouvé différent moment de flush dans le code de rails pour vider ce buffer. Mais voilà, avec script/runner, on peux se retrouver à ne pas avoir flusher tout le logger à la fin de sa tâche. Pour palier le problème, il suffit de faire un RAILS_DEFAULT_LOGGER.flush à la fin du fichier script/runner. Sinon vous pouvez essayer de faire bouger le rapport de bug que j’ai ouvert

Eager Loading empêchant la migration en production

Voulant testé un peu Pictrails avec Edge, pour reporté le bug précédent, je me suis retrouvé bettement à ne pas pouvoir réaliser la migration en mode Production de Pictrails. J’ai ainsi trouvé la cause qui est en fait le eager loading des models durant l’initialisation. Dans mon model Pictures, il se trouve que je fait une demande d’information sur un autre model. Du coup Rails tente de faire une requête SQL avant de réaliser la migration. Forcement, ca peux pas fonctionner. La seule méthode pour éviter ca est de mettre l’option config.classe_cache à false dans le fichier de configuration. J’ai bien sûr reporté un bug à ce sujet.