Thanks for all your work and thinking about this issue, guys, and most of all your patches! I too am unsure whether or not to follow Rails' migration behaviour too closely. I don't have anything against timestamps, but equally I feel that the problem they attempt to address is far less likely to be encountered by plugin developers than application developers (and even then it was relatively rare and could be solved by communication).
Agreed.
So, I'm hesitant to make significant changes at the moment, until we've reached a better understanding of the implications (thanks for starting the discussion by the way, Tekin!).
No worries!
Perhaps a useful way to approach this, for the moment and while Rails itself settles down, is to consider what is currently broken with plugin migrations. As I understand it, the main issue is that migrations generated in an application cannot be moved into plugins because they are named with timestamps. Is that correct?
Yes, partly. The problem is, now a lot of us now have plugins with timestamped mirgations thanks to Sven's fork and Samuel's patch!!
Samuel's/Sven's approach gets my vote - update engines so it tracks each applied migration and then offer a rake task (or even some magic) that upgrades an existing plugin_schema_info table to a plugin_schema_migrations table with applied migrations listed. This would work with both timestamped and sequential migrations.
The only issue I know of with Samuel's patch is that it calls ActiveRecord::Migrator.migrate when migrating, which doesn't scope the applied migrations check by the plugin name, so it will not play nicely if your plugins have migration numbers that clash. _______________________________________________
Engine-Developers mailing list [email protected] http://lists.rails-engines.org/listinfo.cgi/engine-developers-rails-engines.org
