[require] le faire marcher dans tous les cas

Community FR
1

Salut
j’aimerais utiliser dans un modèle un autre fichier.
Pour ça, je place donc un require en début de fichier. Ca marche bien
dans l’applciation Rails, mais pas quand je rake db:migrate, par
exemple.
Comment puis-je donc faire pour que ce require marche dans tous les cas
?

–
Nicolas D.
N’imprimez ce mail que si vous ne savez pas le lire sur l’écran : les
électrons se recyclent bien, le papier, beaucoup moins bien.

2

On 5/24/07, Nicolas D. [email protected] wrote:

Salut
j’aimerais utiliser dans un modèle un autre fichier.
Pour ça, je place donc un require en début de fichier. Ca marche bien
dans l’applciation Rails, mais pas quand je rake db:migrate, par
exemple.
Comment puis-je donc faire pour que ce require marche dans tous les cas ?

Ton require, il est uniquement dans le modèle ? et la migration avec
ce modèle n’arrive pas à utiliser ce require ?

ou c’est :

Ton require apporte des méthodes et tu veux utiliser ses méthodes dans
ton script de migration ?

En fait, j’ai un peu de mal à voir ton cas :frowning:

Peut-être tu peux tenter de le mettre dans le config/environnement.rb

Bonne chance

–
Cyril M.

3

On 5/24/07, Cyril M. [email protected] wrote:

Désolé pour le retard de réponse

Ton require, il est uniquement dans le modèle ? et la migration avec
ce modèle n’arrive pas à utiliser ce require ?

C’est exactement ça.

–
Nicolas D.
N’imprimez ce mail que si vous ne savez pas le lire sur l’écran : les
électrons se recyclent bien, le papier, beaucoup moins bien.

4

On 5/28/07, Nicolas D. [email protected] wrote:

On 5/24/07, Cyril M. [email protected] wrote:

Désolé pour le retard de réponse

Ton require, il est uniquement dans le modèle ? et la migration avec
ce modèle n’arrive pas à utiliser ce require ?

C’est exactement ça.

Ce qu’il faut faire, c’est de ne pas faire de require directement dans
ton model. En effet, si tu as besoin de require dans ton application
rails, il faut utiliser le fichier environnement.rb

Si tu fait ton require dedans et ainsi il sera accessible partout dans
ton application. Le mieux est de mettre aussi ce fichier à rajouter
dans lib/

–
Cyril M.

5

On 5/28/07, Cyril M. [email protected] wrote:

Ce qu’il faut faire, c’est de ne pas faire de require directement dans
ton model. En effet, si tu as besoin de require dans ton application
rails, il faut utiliser le fichier environnement.rb

OK.

Si tu fait ton require dedans et ainsi il sera accessible partout dans
ton application. Le mieux est de mettre aussi ce fichier à rajouter
dans lib/

Oula.
Tu veux dire qu’un truc que je n’utilise que dans un modèle doit être
placé dans le dossier lib plutôt que dans mon diossier models ? Je
trouve ça plutôt curieux. Mais bon, si c’est la convention, et que
çaaide à bien ranger mon code, why not … Et si dans une classe je dois
charger une liste dynamique de fichiers, je fais comment ?

–
Nicolas D.
N’imprimez ce mail que si vous ne savez pas le lire sur l’écran : les
électrons se recyclent bien, le papier, beaucoup moins bien.

6

On 5/28/07, Nicolas D. [email protected] wrote:

ton application. Le mieux est de mettre aussi ce fichier à rajouter
dans lib/

Oula.
Tu veux dire qu’un truc que je n’utilise que dans un modèle doit être
placé dans le dossier lib plutôt que dans mon diossier models ? Je
trouve ça plutôt curieux. Mais bon, si c’est la convention, et que ça
aide à bien ranger mon code, why not … Et si dans une classe je dois
charger une liste dynamique de fichiers, je fais comment ?

Ce n’est pas exact. La seule garantie que t’offre le dossier lib par
rapport au dossier dqsdqs/dqsdqs/dsqdqs c’est qu’il est chargé dans le
load path, tout comme models.

Il faut bien comprendre comment fonctionne require dans rails, quand
on fait un require ‘toto’ rails vérifie si un fichier toto.rb existe
dans les répertoires de la variable globale $LOAD_PATH. Attention
également require est censé ne chargé les fichiers qu’une fois (en
fait bizarrement on peut toujours le faire 2 fois mais pas plus) donc
multiplier les require du même fichier est globalement une mauvaise
idée.

Il faut faire attention avec require car si on l’utilise mal ca va
charger plusieurs fois la même classe et donc potentiellement les
observers seront executés 2 fois…

Ma préférence perso va à require_dependency qui check si la constante
Toto existe et ne charge le fichier que si elle n’existe pas (en plus
ca recharge le fichier à chaque requête en mode development).

Bref quand on se retrouve fasse à un problème de chargement de class
il faut checker plusieurs choses.
-la variable $LOAD_PATH qui contient l’ensemble des répertoires qui
vont être recherché

-est-ce que le model qu’on cherche à charge est bien dans un fichier
correspondant à la camelisation du nom du model (=> Attention à la
single inheritance, les sous classes ne sont pas automatiquement
chargeable quand elles sont dans le fichier même fichier que la classe
mère)

-au cours des migrations d’autres problèmes entrent en compte, la
modification des colonnes d’une table ne sont pas pris en compte si le
model était déjà chargé, ce qui entraine des problèmes très bizarre
parfois, genre update_attribute qui ne fonctionne pas sur les bonnes
column…

A priori au vu de la maigre description du problème il y a fort à
parier que c’est le cas 1 ou 2, le premier truc à vérifier c’est la
variable globale $LOAD_PATH, le deuxième est de vérifier que le
require n’a pas déjà eu lieu au mauvais endroit ce qui empèche le
chargement ici.

Renaud

7

On 5/28/07, Nicolas D. [email protected] wrote:

On 5/28/07, renaud morvan [email protected] wrote:

Ce n’est pas exact. La seule garantie que t’offre le dossier lib par
rapport au dossier dqsdqs/dqsdqs/dsqdqs c’est qu’il est chargé dans le
load path, tout comme models.

Donc, si je place mes fichiers dans l’un comme dans l’autre, ça
devrait marcher … sauf que dans le second cas, ça ne marche pas pour
les migrations.

Alors c’est un problème dans le $LOAD_PATH, en tout cas il n’y a pas
de mystère ca marche, c’est un problème dans ton application.

Je me souviens d’un problème assez tordu en production où le rake
deploy était incapable d’utiliser la version de rails freezé alors que
l’appli l’utilisait sans problème et cela sans retourner d’erreur.

La cause était particulièrement traitre, j’avais une rake task qui
chargait un gems qui n’était pas sur le serveur de production ce qui
fait que lors du chargement de l’environnement les $LOAD_PATH du
freeze gems n’étaient pas utilisés (mais ca ne lancait aucune
erreur…) et finalement ca chargait directement les gems de rails au
lieu de la version
freezé.
La seule manière de traquer ce genre de comportement c’est de suivre
l’évolution de la variable $LOAD_PATH. Le moindre problème dans une
des tasks peut créer ce genre d’effet mais avant de perdre du temps à
vérifier chaque fichier il faut s’assurer que c’est bien ce genre de
problème.

Variable globale de Ruby ?
variable globale ruby, c’est à dire $LOAD_PATH

A priori au vu de la maigre description du problème il y a fort à
parier que c’est le cas 1 ou 2, le premier truc à vérifier c’est la
variable globale $LOAD_PATH, le deuxième est de vérifier que le
require n’a pas déjà eu lieu au mauvais endroit ce qui empèche le
chargement ici.

Pour LOAD_PATH, je ne sais pas. Pour le require, je viens de vérifier,
et il n’est pas fait ailleurs.

Tu ne peux pas le savoir rien qu’en regardant le code car quand tu
utilises Toto dans ton code rails catch les exceptions Constant
Missing et lance automatiquement le require_dependency.
Il faut regarder ce que retourne la fonction “require”. Si ton naming
est bien fait, tu n’as même pas besoin de require.

8

On 5/28/07, renaud morvan [email protected] wrote:

Ce n’est pas exact. La seule garantie que t’offre le dossier lib par
rapport au dossier dqsdqs/dqsdqs/dsqdqs c’est qu’il est chargé dans le
load path, tout comme models.

Donc, si je place mes fichiers dans l’un comme dans l’autre,
çadevrait marcher … sauf que dans le second cas, ça ne marche pas pour
les migrations.

Ma préférence perso va à require_dependency qui check si la constante
Toto existe et ne charge le fichier que si elle n’existe pas (en plus
ca recharge le fichier à chaque requête en mode development).

Effectivement, ça peut être pratique … Je vais tester ça.

-la variable $LOAD_PATH qui contient l’ensemble des répertoires qui
vont être recherché

Variable d’environnement ? Elle n’est pas définie dans mon cas.
Variable globale de Ruby ?

-est-ce que le model qu’on cherche à charge est bien dans un fichier
correspondant à la camelisation du nom du model (=> Attention à la
single inheritance, les sous classes ne sont pas automatiquement
chargeable quand elles sont dans le fichier même fichier que la classe
mère)

Ce n’est pas un modèle, c’est un ensemble de générateurs de contenus
HTML destinés à être utilisés dans des modèles.

-au cours des migrations d’autres problèmes entrent en compte, la
modification des colonnes d’une table ne sont pas pris en compte si le
model était déjà chargé, ce qui entraine des problèmes très bizarre
parfois, genre update_attribute qui ne fonctionne pas sur les bonnes
column…

Sauf si on fait un reset_column_information, je crois.
e problème que j’ai dans les migrations est plus simple que ça. En
effet, tout bêtement, dans mon modèle, lors du before_save, j’appelle
des méthodes de ces générateurs, et ruby ne trouve pas mon fichier.

A priori au vu de la maigre description du problème il y a fort à
parier que c’est le cas 1 ou 2, le premier truc à vérifier c’est la
variable globale $LOAD_PATH, le deuxième est de vérifier que le
require n’a pas déjà eu lieu au mauvais endroit ce qui empèche le
chargement ici.

Pour LOAD_PATH, je ne sais pas. Pour le require, je viens de vérifier,
et il n’est pas fait ailleurs.

–
Nicolas D.
N’imprimez ce mail que si vous ne savez pas le lire sur l’écran : les
électrons se recyclent bien, le papier, beaucoup moins bien.