On Oct 30, 2012, at 2:39 PM, Don Dwiggins wrote: > It appears that, at least currently, Alembic only directly manages tables > (although I guess one could include SQL code in the upgrade/downgrade > functions to add/delete/change SPs, user defined types, functions, etc. > > Am I right in this? If so, do you have any plans or thoughts about > versioning other schema objects?
All of that is accessible via regular op.execute() instructions. There's not much of a win in building hierarchies of Python objects over these constructs as they are only needed for migrations and are highly backend specific. If a more abstracted approach were desired, you're free to define DDL instances and/or DDLElement classes to take advantage of backend-specific compilation forms, events, and other automations, though within the realm of stored procedures and functions there's obviously very little overlap across database vendors. As for the "autogenerate" route, this is where if SQLAlchemy dialects supported dialect-agnostic reflection of SPs and other constructs, Alembic could begin to allow these constructs as well, but that would be a very large project. The Postgresql dialect does have some support for reflection of user-defined domains as well as "enumerated" types, but not yet the catch all "CREATE TYPE" construct. -- 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.
