James, thanks a ton for putting so much work into this. Looking at the long time this has been discussed and the number of attempts to solve it this seems to be something like the "holy grail" of engine plugins.
I've read your blog post but I don't quite get a few problems that you point at. In solution #1 you say that "Next to run is the application's migration, creating a users table, which should not exist. Failure." What's the failure here? The users table won't exist before 20080101_create_users (as long as 20071201_create_accounts does not mess with the users table, which it shouldn't). If I don't get you wrong we've been using a similar approach for a while and it worked well for this scenario. In solution #2 the misconception imho is that the app migrations are run first and the plugin migrations run afterwards. That of course won't work when the app wants to modify what plugins provided. Traditionally plugins were more seen as part of the framework/ libraries, today they also might be parallel slices of an application. In both cases the order "app first, plugins second" seems wrong to me. If anything app migrations would need to run after plugin migrations. Or the timelines need to be mixed. For the "rollback problem", i.e. rolling back all migrations from a plugin: even if plugin migration timestamps are not tracked explicitely one can always inspect the plugin migrations directory. So for uninstalling/rolling back a plugin a dedicated rake task could work that looks at the plugin migrations folder and migrates the plugin down. This obviously would clash when the app messed with the plugin's tables and one would need to migrate the app migrations down manually ... which imo seems ok though. On 15.03.2009, at 21:29, James Adam wrote: > > On Mar 15, 7:35 pm, David Masover <[email protected]> wrote: >> On Sun, Mar 15, 2009 at 7:17 AM, James Adam <[email protected]> >> wrote: >>> I'd invite you to look athttp://interblah.net/plugin-migrations >>> for a >>> more in-depth 'think-through' of why this is important, but do let >>> me >>> know if you're still not convinced. >> >> Ah, I see your point. >> >> I am still not convinced that it needs to be duplicated -- I would >> still opt >> for a symlink, > > Alas, it's not cross platform, and so while that'd be nice, we have to > ignore its appeal. > >> or maybe something like it: >> >> MigrateBarInPluginFoo = >> SomePluginModule.some_helper_method :Foo, :Bar >> >> Or, better: >> >> MigratePluginFooTo20081124174854 = some_helper_method :Foo, >> 20081224174854 > > I'm not really sure what you have in mind here, but I'm happy to chalk > that up to my poor understanding - if you feel you have a good idea, > please do investigate (as they say :)). I am be no means wedded to my > patch, except that so far I feel it is the most likely-to-be-applied > solution that meets the criteria outlined on interblah.net. > >> And version control >> should really be about tracking the user's own creations and >> changes -- and >> this is all the user did, they very likely didn't change anything >> about the >> content of the migration. > > I'm not sure this is a very useful way of thinking about version > control. Rather than caring about what the user directly did, version > control (imho) is about preserving the state of the application at any > particular point in time, such that we can return to that state and be > confident that we have (or can) undo any changes between our current > state, and that desired previous state. Anyway, that's a bit of a > tangent, and it's probably less useful to this discussion to go into > much more detail about it. > >> Of course, probably the biggest reason this disagrees with me is >> that I >> don't really see that a plugin should conflict with existing tables. >> Ideally, the plugin should have namespaced models, for precisely this >> reason. > > Whether conflicts are likely or not is secondary (again imho) to the > fact that they *will* occur, and whatever mechanism employed should be > robust enough to handle it. It's my feeling that it won't be uncommon > for users to want to add a column here or there. > >> If there's really a potential problem of conflicting migrations, >> the extra >> column on schema_migrations would solve that, right? > > Solving conflicts really means ensuring that migrations are applied in > the same order every time - so they're reversible. The only benefit > the extra column would give is make it simpler to track *which* > migrations have been run; we'd still need to introduce a new migration > (or stub migration or something) to mark when in the timeline those > migrations were applied. So the extra column itself does nothing to > prevent conflicts, unfortunately. > > I hope that's clear - thanks again for taking the time to consider > this. > > Anyone which commit rights care to indicate if any of this discussion > is likely to be useful? :) > > Thanks again, > > 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 [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
