On 19/04/2012 18:43, Michael Bayer wrote:
but with the possibility of dependencies between those tables. If I
understand correctly, if we were dealing with sets of tables that didn't
have any dependency, you wouldn't need a distributed migration tool,
each package would handle migrations for its own set of tables
independently, is that right ?
This is what I came up with for mortar_rdb: each package defined a
"source" of tables and each application collected the sources it was
using into a "config". Each "source" has its own schema. I haven't hit a
situation where I needed the topological sort yet, I suspect if I did
I'd just punt and make the owner of the config (ie: the application)
specify the upgrade order manually...
I think what I need to see here are, what exactly are these packages,
Authentication, authorization and "membership" are the obvious ones; all
three have several interchangeable solutions and I can certainly
conceive packages for each interoperating with a few select foreign
keys, username being the most obvious...
Admittedly, I haven't hit this in the "real world" yet.
I'm very keen to move mortar_rdb onto Alebic, and will be doing so as
soon as I hit the need in the real world...
Chris
--
Simplistix - Content Management, Batch Processing & Python Consulting
- http://www.simplistix.co.uk
--
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.
