Ummm, what? LOL. In the heat of the battle I picked the wrong email from my drafts folder and hit "send" without even noticing it. The subject was so similar.
Anyway. James, I wanted to put more thought into this before sending a reply but maybe this at least helps with keeping the discussing running ;) On 31.03.2009, at 11:52, Sven Fuchs wrote: > > 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 -~----------~----~----~----~------~----~------~--~---
