I thought I’d post here as the ticket relating to this issue was
getting a little cluttered with comments.
I’m trying to stimulate some debate as to the best way to proceed with
regard to how engines handles migrations with Rails 2.1 and beyond as
I don’t think the current 2.1 release is ideal - it doesn’t handle
timestamped migrations in plugins.
Inspired by Azimux’s fork, I’ve made an attempt at a solution
that ditches the plugin_schema_info table altogether and relies on the
Rails migrator to migrate plugins up and down. This works great if you
are starting with a fresh app and/or have timestamped migrations in
your plugins. It’s not so great if you are upgrading an existing app
to 2.1 or your plugins have sequential (and potentially clashing)
migration version numbers.
Now the questions are:
How bad would it be to break compatibility?
Can a rake task/automatic process (ala Rails 2.1) be created to offer
a painless upgrade?
Can we have a tag for a ‘legacy’ version, with the timestamp ready
version as head?
I don’t think there are any simple answers here, but I do feel
strongly that engines should keep parity with Rails and start using
Sven’s fork and Samuel’s patch both offer alternative solutions
which use a plugin_schema_migrations table to track applied
migrations, but both suffer from the same problem - they don’t
distinguish between plugins when checking if migrations have been
applied so don’t behave correctly if plugins have migrations with
clashing version numbers.
My feeling is that going down the route Sven and Samuel have proposed
is probably the easiest way to maintain backwards compatibility while
supporting timestamped migrations. It would also be relatively trivial
to modify the migrator to automatically bootstrap the
plugin_schema_migrations table in the same way Rails does with
schema_info table. Personally though, I think a simplified engines
migration mechanism as in Azimux’s and my fork would be better in the
long term as it overrides less of Rails’ default behaviour.