On Apr 23, 2012, at 2:14 PM, Don Dwiggins wrote: > I've looked at Migrate with a particular application in mind (that I won't be > able to get started on for a while), and now I see that Alembic is its > successor. So, hoping to be able to use Alembic, and maybe influence its > development, a couple of questions: > > I have a large, fairly complex MSSQL schema, with hundreds of tables and SPs, > views, triggers, etc. I'd like to "put it under change management". Is this > feasible with Alembic? If so, what would be involved in getting started? > Also, I'm dealing with multiple customer databases using this schema, and not > all at the same "revision level". Would it be feasible to use Alembic in > this kind of situation? > > To add a wrinkle: we're starting work to port the schema to PostgreSQL. > Could we manage the MSSQL and PostgreSQL implementations in parallel with > Alembic?
I use Alembic in production with a Postgresql/MSSQL hybrid situation so the operations are most finely tuned to these two backends in any case at the moment. You can apply a migration tool to a schema at any point in its lifetime, basically whatever state the schema is in when you start, that becomes the initial version. Changes to the schema subsequent to that point are then maintained as migration scripts. So you can pretty much install Alembic as detailed in the tutorial and start going. The autogenerate feature is very useful too, to use that, you'd need to also provide to the Alembic environment a handle to your application's table metadata (i.e. a SQLAlchemy MetaData object). autogenerate can compare that to the current status of the database. This also would require that every table in the target database is also represented in your ORM/MetaData model. At some point we'll be adding more options to tune autogenerate better for very large schemas that have tables beyond that which are represented in the model. It's a challenge that you have databases out in the wild that are not in sync. To the degree that those differences are important to the migration scripts you'll be writing, you'll want to get those systems in sync first - depending on the situation you might want to write scripts for each customer's database individually, each of which will have the job of getting that database into shape for the primary set of migration scripts. You might use Alembic to help you write these scripts too, at this point the tool is open ended enough that you can use its migration directives in a regular script, there's an example usage of that at http://alembic.readthedocs.org/en/latest/ops.html#alembic.operations.Operations. > > Thanks, > > -- > > Don Dwiggins > Advanced Publishing Technology > > > -- > You received this message because you are subscribed to the Google Groups > "sqlalchemy" group. > To post to this group, send email to sqlalchemy@googlegroups.com. > To unsubscribe from this group, send email to > sqlalchemy+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/sqlalchemy?hl=en. > -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalchemy@googlegroups.com. To unsubscribe from this group, send email to sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
