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 -~----------~----~----~----~------~----~------~--~---
