Migrations

Community FR
1

Bonjour,

je suis en train de bidouiller sous Rails, mais je viens de m’apercevoir
que je n’ai pas vraiment compris le fonctionnement des migrations.

Pour initialiser mon projet, j’avais réalisé ceci :

* ruby script/generate migration add_a_new_table
* Edition du fichier db/migrate/001_add_a_new_table.rb, et insertion
  de mes tables
* finallement, rake migrate et tout c'était bien passé

Mais aujourd’hui je veux faire une version 2 de cette migration (et oui
je me rajoute une table ! :p), mais je n’arrive pas à obtenir un fichier
db/migrate/002_add_a_new_table.rb et j’ai le message suivant :
/ exists db/migrate
Another migration is already named add_a_new_table:
db/migrate/001_add_a_new_table.rb/

Pourtant mon schéma.rb contient bien :
ActiveRecord::Schema.define(:version => 1)

et pour que la gestion de version se fasse correctement j’ai dans mon
config/envirronement.rb :
config.active_record.schema_format = :ruby

Comment faire svp pour que je puisse créer une version 2 de mon script
de migration ?

2

Salut,

2 migrations (qui se suivent du moins… je pense là je ne me suis
pas amusé à testé) ne peuvent avoir le même nom.

L’idée des migration c’est qu’elles aient un nom qui ait un sens.
Comme adding_events_users_and_jobs_tables.

Si aujourd’hui ce nommage ne t’es pas extrêmement utile bienq ue cela
puisse aider quand son propre projet grandi, le jour où tu
travaillera avec quelqu’un le nommage devient une bonne chose :slight_smile:

à +
NP

Le 9 oct. 06 à 18:36, edouard cante a écrit :

3

Salut Edouard,

Mais aujourd’hui je
veux faire une version 2 de cette migration (et oui je me
rajoute une table ! :p), mais je n’arrive pas à obtenir un fichier
db/migrate/002_add_a_new_table.rb et j’ai le message
suivant :
exists db/migrate
Another migration is already named add_a_new_table:
db/migrate/001_add_a_new_table.rb

Ce n’est pas possible d’avoir 2 migrations avec le même
nom, car à ta migration add_a_new_table, va correspondre
le nom camélisé AddANewTable qui va être le nom de ta
classe fille de AR::Migration.

Donc on a intérêt à :

  • limiter si possible le nbre de migrations car “ça pollue
    l’espace des noms” (ie alter_users_table n’est dispo qu’une
    fois)
  • à éviter des noms génériques : create_a_new_table,
    mais privilégier des noms plus précis :
    add_position_column_to_categories_table

Comment faire svp pour que je puisse créer une
version 2 de mon script de migration ?

enfin tout dépend si ton appli rails est sous SCM ou
non.

1/ Si oui, il faut bien réfléchir avant de commiter,
vérifier si ça migration marche, si on peut pas l’améliorer,
(pour éviter d’avoir à rajouter une colonne à une table que
l’on vient de créer lors de la précédente migration).

2/ Si non, et si ça ne pose pas de pb de revenir tout au
début (appli en tout début de construction, aucunes données,
on bidouille), autant recommencer la première migration que
j’appelle généralement initial_schema.
Ainsi dans ton cas, tu peux revenir à la version 0
rake db:migrate VERSION=0
rajouter la création de ta table dans le fichier de migration 1
(que j’appelle 001_initial_schema.rb pour ma part)
remigrer en version 1.

Certains préfèrent peut être séparer les créations de table
dans des migrations uniques.

Mais je préfère l’optique, une grosse migration en 1 (Ã
la place d’une dizaine de migrations table/table) et
on peaufine dans les migrations après.

Un des inconvénients, c’est qu’on perd la génération automatique
de la migration lors du script/generate model.

Pour l’instant je parle du début du codage de ton appli,
où rien n’est encore livré, ni dispo pour le reste de l’équipe
ou pour le public.

-- Jean-François.
4

re

Ce n’est pas possible d’avoir 2 migrations avec le même
nom, car à ta migration add_a_new_table, va correspondre
le nom camélisé AddANewTable qui va être le nom de ta
classe fille de AR::Migration.

Ah oui oups, sur le coup mon esprit a oublié le fait que l’on créait
une classe par migration… Merci Jean-François.

NP_______________________________________________
Railsfrance mailing list
[email protected]
http://lists.rubyonrails.fr/mailman/listinfo/railsfrance

5

Nicolas P. a écrit :

NP_______________________________________________
Railsfrance mailing list
[email protected]
http://lists.rubyonrails.fr/mailman/listinfo/railsfrance

Merci beaucoup pour ces réponses !!

6

Quand je suis en mode pur dev (quand je n’ai pas encore l’appli en
prod), je me permet d’écrire directement dans le fichier de migration,
au lieu d’en générer un pour rajouter une colonne ou 2.
Ensuite, un petit “rake migrate VERSION=XXX && rake migrate” et ça roule
(on ne va pas se compliquer la vie quand ce n’est pas nécessaire non ?).
XXX vaut le “niveau” à partir duquel on veut “rejouer” les migrations.
Et avec rake db:fixtures:load je peux rajouter facilement un jeu de
données.

++

yk

Eric R. a écrit :

7

L’approche que j’utilise est la suivante :
1/ je crée toujours les nouveaux Model avec ‘script/generate model XX’
(ex:
script/generate Car) ceci a l’avantage de créer tous les fichiers
nécessaires, y compris le squelette du fichier de migration pour créer
le
dit Model (avec la bonne numérotation en prime) qu’il suffit ensuite de
remplir.
2/ si j’ai besoin d’ajouter une colonne à un Model déjà existant, alors
j’utilise ‘script/generate migration’ (ex: script/generate migration
add_car_name) et je le remplis de même.

Eric