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 ) --~--~---------~--~----~------------~-------~--~----~ Vous avez reçu ce message, car vous êtes abonné au groupe "Railsfrance" de Google Groups. Pour transmettre des messages à ce groupe, envoyez un e-mail à l'adresse [email protected] Pour résilier votre abonnement envoyez un e-mail à l'adresse [EMAIL PROTECTED] -~----------~----~----~----~------~----~------~--~---
