On Oct 16, 8:55 am, Nate Wiger <[email protected]> wrote: > Since we're on topic, I was actually going to post a question about > auto-migrations. Basically, I'm going to have to implement auto- > migrations functionality that works with Sequel anyways, since we rely > heavily on it at my work. (Right now we're using AR with > auto_migrations). A large part of our app is dynamically generated > based on configuration metadata (since we reuse the same XML/JSON core > on vastly different games), so standard ordered database migrations > fall apart pretty quickly. > > If you're interested in adding auto-migrations to Sequel, I'll take > the time to properly structure it, etc. If not, I'll just write a > throwaway Rake task and call it done. The reason I was asking about > set_schema is that seems like the way to go for auto-migrations, since > it has the advantage that all your model-related code is in one file.
Model.set_schema combined with Model.create_table* can be used to automatically create the table's schema, but they aren't really migrations, as the don't work well with existing data. You can use Model.create_table! to drop an existing table and rebuild it, but I doubt that's what you want. > Anyways, for the non-throwaway version, I was thinking two methods: > > DB.recreate_schema! > DB.upgrade_schema! > > There could also be support added to the sequel command-line tool. > (I'm not heartset on these names, but personally I find the DataMapper > differentiation between auto_migrate! and auto_upgrate! too subtle.) > > Anyways, having patched the AR auto_migrations plugin and from looking > at DM's code, there's a medium amount of work for the core > functionality, but luckily, alot of the logic can be cut-and-pasted > from those two respective projects and just adapted to Sequel's > internals. > > If you're not interested in shipping this with Sequel, I can always > make an external plugin and throw it on github, but either way I'd > like to approach it in a way that you generally agree with if > possible. I'm against auto migrations as there really isn't a way to do things properly. Let's say you have this schema: CREATE TABLE items ( id INTEGER PRIMARY KEY, number_of_items INTEGER ); And you want to migrate it to this schema: CREATE TABLE items ( id INTEGER PRIMARY KEY, num_items INTEGER ); There is no possible way for an automigrator to know to do a column rename instead of a drop column and add column. Recreating schema automatically in the simple case is easy in Sequel, but you still need to worry about dropping/adding tables in a certain order if you want to enforce foreign key constraints. There is a lot of complexity required to deal with the corner cases of just that correctly. Alternatively, you can just delay adding the foreign key constraints until after all tables have been defined. That's the route I'd take if I wanted autorecreation. I think that this type of feature is best kept in an external extension. Jeremy --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "sequel-talk" 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/sequel-talk?hl=en -~----------~----~----~----~------~----~------~--~---
