On Mar 12, 1:38 am, Josh Susser <j...@hasmanythrough.com> wrote: > Desert creates a parallel table for plugin migrations: > plugin_schema_migrations. It's like the app's schema_migrations > table, but each row has both a version and a plugin name. Migrations > in plugins are accessed by putting a method call in an app migration > that migrates to a particular migration version in the plugin - it's > not automagic, but it works quite well.
That's effectively a mash of two implementations in the history of how the engines plugin enabled migrations (the separate table to track what's been run from where, and the app migration to ensure the timeline is preserved), so I can definitely relate to how it works. However, the point here is whether or not we can make this functionality available as part of the core system, and how to do that with a balance of simplicity and elegance. Given that vanilla plugins can contain models, it makes sense that they should also be able to produce the tables required by those models. I've boiled things down to two possible implementations that satisfy all required functional goals - one based on the existing implementation in the engines plugin (and so Desert too), or a simpler Rake task. After spending some time discussion what was likely to be incorporated, I decided not to pursue any solution that modified the migration tables (either by adding a new table or adding a 'source' column to the default one); David just wasn't into it. Hence the current patch, on which it'd be great if you commented specifically. Thanks, James --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
