> Rick -- > That's a really slick way to handle this problem! I'm going to have to > give that a try. That makes my day. > > So -- any similarly slick ideas on how to handle the "I want to add a > local migration without getting stomped by the upstream" issue I was > jabbering about at the beginning? > > Thanks, > Rick > -- > http://www.rickbradley.com MUPRN: 497 > | all those negative > random email haiku | vibes get you? <fade out> Seen > | both movies. They rock.
That's a tricky issue. Off the top of my head, I'd suggest creating an alternate migration directory for local migrations, as well as a separate table for that. I can see something like that used for an extensible app, such as Typo. Each component or plugin would have it's own directory of migrations, with its own row in a plugin_migrations table to keep the current version number. "Uninstall" a plugin would run those backwards to completely deactivate it from the system, while "installing" would run some kind of master migration (similar to the schema.rb for your application). Even if you could utilize migrations and somehow sneak a change or two in, how would you roll your changes back? You'd have to rollback all the recent typo changes, then your local changes, and finally re-run the typo migrations. Yuck. That's why I suggested a separate location for the localized migrations. It sounds like Too Much Software for Rails to handle out of the box. It might make a good plugin, however. I think Rails Engines accomplishes this, but I'm not sure how. -- Rick Olson http://techno-weenie.net _______________________________________________ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
