Comment creer des groupes de migration indépendants?

Salut,

J’ai crée un petit CMS permettant de traiter différentes applications.

Par exemple je suis en train d’ajouter un module de blog au CMS et je
souhaiterai traiter les tables du BLOG de maniere distincte de celles du
CMS.

Est ce qu’il est possible de créer un sous dossier de migrations du
genre db/migrate/blog ou alors il est impossible de gérer des groupes de
migration ?

Je ne sais pas comment vous faites mais moi je me retrouve vite avec un
truc ingérable à ce niveau.

frio

On Nov 12, 2007 11:24 AM, Frioffol F.
[email protected] wrote:

genre db/migrate/blog ou alors il est impossible de gérer des groupes de
migration ?

Je ne sais pas comment vous faites mais moi je me retrouve vite avec un
truc ingérable à ce niveau.

Il n’est pas possible selon moi de gérer les migrations par
“sous-projet”. Normalement les migrations n’ont pas lieu d’être
vraiment lu indépendement. Elles ne permettent qu’une évolution de la
BDD. La seule chose faisant vraiment fois dans ton environnement
globale est le schema.

Je ne pourrais donc que te conseiller de préfixer le nom de tes
migrations par le module que tu veux faire évoluer avec ex :

0xx-BLOG-add-table
0x1-CMS-add-index
etc…


Cyril M.
http://blog.shingara.fr

Frioffol F. a écrit :

migration ?

Je ne sais pas comment vous faites mais moi je me retrouve vite avec un
truc ingérable à ce niveau.

frio

Salut,

une piste à creuser peut être les différents plugins qui permettent de
gérer des migrations en parallèle. Le besoin initial était surtout
d’éviter les conflits sur les fichiers de migration avec SVN, mais vu
qu’il existe au moins 3 ou 4 plugins permettant ça, j’imagine que
certains ont des fonctionnalités plus avancées qui pourraient répondre à
tes besoins.

Quelques points de départ :
http://andy.delcambre.com/2007/9/19/migration-conflicts
http://revolutiononrails.blogspot.com/search/label/migrations
http://blog.teksol.info/tags/migrations

++
Bruno M.

Bruno M. wrote:

Frioffol F. a �crit :

migration ?

Je ne sais pas comment vous faites mais moi je me retrouve vite avec un
truc ing�rable � ce niveau.

frio

Salut,

une piste � creuser peut �tre les diff�rents plugins qui permettent de
g�rer des migrations en parall�le. Le besoin initial �tait surtout
d’�viter les conflits sur les fichiers de migration avec SVN, mais vu
qu’il existe au moins 3 ou 4 plugins permettant �a, j’imagine que
certains ont des fonctionnalit�s plus avanc�es qui pourraient r�pondre �
tes besoins.

Quelques points de d�part :
http://andy.delcambre.com/2007/9/19/migration-conflicts
http://revolutiononrails.blogspot.com/search/label/migrations
http://blog.teksol.info/tags/migrations

++
Bruno M.

cyril, c’est ce que j’utilise comme méthode

merci bruno pour les infos.

je vais creuser la piste du premier lien et le “independent migration”
qui semble pouvoir être une solution.

merci encore

Bruno :

une piste à creuser peut être les différents plugins qui permettent de
gérer des migrations en parallèle. Le besoin initial était surtout
d’éviter les conflits sur les fichiers de migration avec SVN, mais vu
qu’il existe au moins 3 ou 4 plugins permettant ça, j’imagine que
certains ont des fonctionnalités plus avancées qui pourraient répondre à
tes besoins.

Quelques points de départ :
http://andy.delcambre.com/2007/9/19/migration-conflicts
http://revolutiononrails.blogspot.com/search/label/migrations
http://blog.teksol.info/tags/migrations

Une autre piste est de regarder les systèmes qui ont des logiques
de plugins/composants. Par exemple, chez Plugin a week, avec
le plugin plugin_migrations

http://www.pluginaweek.org/2006/11/05/3-plugin_migrations-where-have-all-the-migrations-gone
http://wiki.pluginaweek.org/Plugin_migrations

ou chez Radiant CMS, avec les extensions et le système de migrations
(pour les arcanes du système, demandez Jean-Mi !).

L’idée est d’avoir une table dédiée qui contient des métadonnées
sur les plugins/extensions et notamment un numéro de version
par plugin/extension et non en se basant sur schema_info.

Pour plugin_migrations, la table est plugin_schema_info ; pour
les extensions de Radiant, c’est extension_meta.

Rails Engines a sûrement aussi son système de migrations.

Il est intéressant d’étudier leur manière de m/patcher les migrations
de Rails.

– Jean-François.


Ruby ( http://www.rubyfrance.org ) on Rails ( http://www.railsfrance.org
)