Hey guys,
first of all please accept my apologies for ignoring your discussion
for so long. I'm up to my ears in other stuff and did not have any
time to review all of your work.
So although I most certainly won't be able to actually contribute any
code I'd still like to throw my thoughts onto the table.
My fork was referenced a couple of times. I don't feel strong about
this implemetation. It was just the easiest thing I found to work and
got it done. I'm sure I missed a couple of issues. (Although I'm
actually already using it.)
I feel strong about Engine migrations being as much aligned to Rails
migrations as possible. Not so much for technical reasons (clashes
aren't that likely, although still can occur etc.) but more for
reasons like "framework usability" and education. I really don't want
to wrapp my head around wondering how Engine migrations behave
different from Rails migrations on certain edge cases. And I don't
want to explain it. It's hard enough for me to remember how Rails
migrations work with certain conditions given. So, from my point of
view that would be the most important goal: having Engines migrations
transparently work exactly how Rails migrations work.
I personally don't care too much about backwards compat in this case.
I'd implement things in a way that is "done the right way" for Rails
2.1+ and on top of that maybe have a rake task or whatever tool to
update migrations from old apps.
If we want to support numbered migrations (as Rails still does)
tracking migrations per plugin (in an extra table) is necessary.
On 22.07.2008, at 00:30, Tekin Suleyman wrote:
Hi,
I thought I'd post here as the ticket relating to this issue[1] 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[2], I've made an attempt at a solution[3]
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
timestamped migrations.
Sven's fork[4] and Samuel's patch[5] 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.
Thoughts?
Tekin Suleyman
http://tekin.co.uk
[1]
http://engines.lighthouseapp.com/projects/10178/tickets/17-migrations-do-not-work-beyond-the-initial-migration
[2] http://github.com/azimux/engines/tree/master
[3]http://github.com/tekin/engines/tree/master
[4] http://github.com/svenfuchs/engines/commits/master
[5] http://engines.lighthouseapp.com/attachments/32727/engines.diff
_______________________________________________
Engine-Developers mailing list
[email protected]
http://lists.rails-engines.org/listinfo.cgi/engine-developers-rails-engines.org
--
sven fuchs [EMAIL PROTECTED]
artweb design http://www.artweb-design.de
grünberger 65 + 49 (0) 30 - 47 98 69 96 (phone)
d-10245 berlin + 49 (0) 171 - 35 20 38 4 (mobile)
_______________________________________________
Engine-Developers mailing list
[email protected]
http://lists.rails-engines.org/listinfo.cgi/engine-developers-rails-engines.org
