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;
Don't be sorry, I'm not even sure I agree with myself anymore! As you
say the more we think about it the better.
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.
I agree, although this problem applies to migrations in Rails too! At
any rate, my understanding of engines is that it's really been
designed for creating plugins for internal use across projects rather
than public consumption. But yes, potential clashes are bad.
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 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).
This is the main reason I'm starting to feel my solution isn't the way
to go.
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 think I agree, but this is exactly the magic that Rails 2.1 performs
when you upgrade.
From my understanding, Sven's fork only works if you're starting from
fresh, there is no fixing of the old plugin schema table. One things
it does do though is restrict the filename length of generated plugin
migrations; useful as they can get very long with timestamps in them!
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.
Having slept on it, I'm not sure I do anymore! I think I was seduced
by the fact it used less code, overrode less of Rails' functionality
and needed one less table to work.
I think from my point of view - relying on Rails core is sometimes
more difficult because it can be a moving target.
Indeed, as Murray's post has just proved!!
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.
I agree, although for arguments sake, it seems to me that engines has
always strove to be less code and have Rails do more of the work, as
happened when Rails added multiple view paths support. In a way, the
solution in my fork is doing something similar (multiple migration
path support!?) but may ultimately be a bit premature.
Tekin
_______________________________________________
Engine-Developers mailing list
[email protected]
http://lists.rails-engines.org/listinfo.cgi/engine-developers-rails-engines.org
