Créer des données référentielles en RAILS

Rails, comme disent les jeunes, ça roxxe.
Si il ya des jeunes parmi vous, ils se reconnaîtront.
Mais quand on commence Rails et qu'on a l'habitude d'autres langages - des langages de vieux, notamment -, on se pose des taaaas de questions.
Par exemple : comment utiliser proprement des données référentielles issues d'une classe dans mon code ?

Mon problème : j'ai des objets qui référencent la classe Status, une classe simplette qui comporte :
- un code de référence en string
- un label en string

J'ai 3 statuts différents, notamment parce que j'aime bien le chiffre 3. Cette classe n'est pas amenée à évoluer ; du coup, je n'ai prévu aucun écran pour insérer des données.
Du coup, comment fais je ? Hein ? A votre avis ?

Après avoir fouillé le Net, j'ai trouvé des informations relatives aux Fixtures ; pas bon pour moi, cela s'applique plutôt aux tests.

Une solution, plutôt élégante, est d'aller modifier le script de migration de création de la table.

class CreateStatuses < ActiveRecord::Migration
def self.up
create_table :statuses do |t|
t.string :code
t.string :label
t.timestamps
end

# Initialisation des donnees
Status.create :code => "AFAIRE", :label => "A faire"
Status.create :code => "ENCOURS", :label => "En Cours"
Status.create :code => "TERMINE", :label => "Termine"

end

def self.down
drop_table :statuses
end
end

Les données sont créées par la ligne "Status.create".

Donc :
1. Je crée le modèle, le controleur et le script de migration par un Scaffold des familles
2. J'exécute un "rake db:rollback" pour annuler la création de la table
3. J'édite le script de migration précédemment créé par le Scaffold en ajoutant mes lignes de Ma_Classe.create ...
4. Je fais un rake db:migrate pour créer ma table et la peupler.

Et pis crac. Etonnant, non ?
Previous
Next Post »

2 commentaires

Write commentaires
Adrien Thery
AUTHOR
23 septembre 2011 à 01:56 delete

Les migrations sont probablement une des choses les plus géniales de Rails quand on le découvre.

Une remarque issue de 10 mois de déeloppement sur une appli Rails récemment, et donc de la création de dizaines de migrations successives : utiliser les migrations pour insérer ou modifier les données en base pose des soucis.

En effet, imagine que le 1 fevrier, tu crée une migration pour remplir la table des administrateurs : tout se passe nickel.

le 1er mars, tu ajoutes un champ et une validation à ton administrateur, pour rendre ce champ obligatoire : PAF! Ton intégration continue, qui , j'en suis sur (clin d'oeil) reconstruit chaque fois la base à partir des migrations successives, passe au rouge. Alors que vas-tu faire ? modifier ta vieille migration ? Pas terrible : réécrire l'histoire... et si tu impactais d'autres migrations depuis ? Une bonne pratique générale est de ne pas toucher aux anciennes migrations, mais d'en créer une. Gardons en tête que ces migrations sont incluses dans ton gestionnaire de source, et donc, doivent rester en phase avec le code applicatif de leur commit !

Il vaut donc mieux, je crois, utiliser un script de seeding (hop : rake seed) que tu pourras executer quand tu le souhaites (l'init d'un nouvel environnement, ton intégration continue, etc). Il y a des gem pour ça, également.

Vala, mes 2 centîmes, comme on dit :)

Adrien

Reply
avatar
Waldorf
AUTHOR
23 septembre 2011 à 09:41 delete

Ah c'est une excellente remarque... Je pensais surtout aux données référentielles censées "ne jamais bouger". Ce qui il est vrai dans la réalité peut parfois faire doucement rigoler.
Et il est vrai que les migrations fournissent une souplesse d'usage rarement égalée... Les vieux réflexes ne sont hélas jamais très loin ;)

Reply
avatar