On Sun, Mar 7, 2010 at 6:49 PM, Jeremy Kemper <jer...@bitsweat.net> wrote: > I have a plugin with migrations for its own database. I want those to > run and be managed in their own universe. This works well today using > our existing tools: just override the connection class method on the > migration.
Even if a plugin/engine manages its own database, and has nothing to do with your app's database, it still operates within the context of your app and your app's timeline (you explicitly upgrade the code, you monkey patch it, etc). Otherwise, if it has nothing to do with your app, it is a separate app in itself, and should be managed independently. But since it *is* in the context of your app, it makes sense to explicitly manage the plugin's migrations within the timeline of your app's migrations. You need to have explicit control over this timeline, for all the reasons Josh mentioned in his response. The migrations API should definitely support either approach - running an engine's migrations as a standalone app, or invoking them in the context of a parent app's migration timeline - and I hope Josh's patch takes this into account. This allows for the greatest flexibility, but we must support both. -- Chad -- 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-c...@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.
