On 22/07/2008, at 10:30 AM, 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.
Thanks for your work. I'm sorry I have to have a negative response to
it, but I'm still thankful you took the time to work on it, because
the more we think about this problem, the better solution we could
come up with;
I don't think this is a good idea for one fundamental reason - it is
logically broken. It may be very rare that two migrations end up with
the same timestamp, but it could happen. In this case, behavior is
undefined, which I think is very bad. Behavior in this case needs to
be defined.
Picture the following scenario. There are two separate developers
creating Engine A and Engine B. Both have the same time stamped
migration. Who's responsibility is it for the time stamp to be
changed? Are we going to make all time stamp migrations unique, in the
entire world? Plugins exist in their own namespace - migrations like
these shouldn't be treated the same - thus it makes sense for the
migration table to have a namespace ("plugin_name" column) associated
with it.
Now the questions are:
How bad would it be to break compatibility?
Very very bad, in my opinion. This is not an option in many cases. At
release, all previous engines would need fixing. Backwards
compatibility is a must for people to take any forward movement
seriously, in my opinion.
Can a rake task/automatic process (ala Rails 2.1) be created to
offer a painless upgrade?
Yes, it would be possible to code this. You can see the rake task in
my patch which does twiddling for the specific requirements of my patch.
Can we have a tag for a 'legacy' version, with the timestamp ready
version as head?
What about plugins that use both? An old engine of mine uses both the
old indexed format and timestamped format. Rails 2.1 officially
supports both methods AFAIK (feel free to correct me if wrong).
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.
That's true - there is no simple answer, however maintaining parity
may not be the right goal. I think fundamentally, the most important
thing is that it works, and that it works in a logical dependable way,
and that it doesn't have unexpected behavior.
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?
My patch and Sven's fork both achieve the same thing. I'm still
unclear on whether Sven has addressed fixing the old schema table or
not. My patch includes a rake task for this. This task can be used
when upgrading to rails 2.1. Having automatic magic in the migrator to
bootstrap the schema table may be a good idea, but it might be too
much magic - keeping the rake task as a task and maybe just logging an
error from the migrator with appropriate information might be a better
way to go.
I'm not sure why you think it would be better in the long term.
Plugins are inherently in their own namespace, therefore, in my
opinion, the schema table is just fine.
I think it would be good for you to summarize in what ways you think
that it is better in the long term, this way I can understand more
clearly what you are thinking.
I think from my point of view - relying on Rails core is sometimes
more difficult because it can be a moving target. If we can integrate
the functionality together between engines and rails to the point
where engines can be pulled along with rails, then we have achieved
something great. However, if we integrate the two and are constantly
playing catch up, then this is a difficult situation. At this point,
we are playing catch up to a major feature change - but as I see it,
this isn't such a bad thing, because the change we are making is
actually a significant feature to engines in its own right - i.e. the
new time stamped migrations is a benefit to engines, not just playing
catch up.
In this regard, any new feature will require time and effort to
integrate cleanly. Even if engines relies on 90% of rails, it will
still require some kind of update when the core changes, for that 10%
which might not quite be right anymore. It is a fine line, but if
engines maintains its own independence where it makes sense, it might
actually end up being less highly coupled and require less
modification when rails changes. Does that make sense? More coupling =
more work generally, less coupling = less work generally. What you are
suggesting appears to be more coupling.
Kind regards,
Samuel
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
_______________________________________________
Engine-Developers mailing list
[email protected]
http://lists.rails-engines.org/listinfo.cgi/engine-developers-rails-engines.org
