On Thursday, April 19, 2012 1:43:59 PM UTC-4, Michael Bayer wrote: > > If you've seen my recent talks you saw that I'm a little skeptical of what > you're terming "non-monolithic" databases. Let's say this means, a > database with a set of tables maintained by entirely different packages, > 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 ? > > I think what I need to see here are, what exactly are these packages, > outside of the Django community, that actually create their own tables yet > encourage dependencies between those tables and your app's own tables ? I > know people are working on them since I see people asking questions about > those use cases, but what are they ? What's the openid and user/groups > package you're thinking of here ? >
I think you are right, there isn't anything outside of the Django world that does this; stucco_evolution is my attempt to bring something like that kind of re-use to my non-Django-powered world, and as far as I can tell*, I am its only user. * Koders code search Admittedly so far the only use case is the users/groups schema where the application attaches a separate user profile table, just like Django. The relationships always go in only one direction: the dependent schema holds a foreign key referencing the dependency schema. It really is possible to distribute the entire user management interface as a separately maintained package, while still being able to get at user.profile in your app, but you won't be able to perform migrations that change the user table's primary key. It's probably more useful that stucco_evolution makes sure the users table is simply created first. In the openid case, an openid package manages a users_openids table instead of adding an openid column to the users table. So there you have it. It very well may be that there is exactly one use case for this package, but who doesn't need to keep track of users and groups? Other than that it does a passable job of applying hand-written linear database upgrades, and it is short. -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To view this discussion on the web visit https://groups.google.com/d/msg/sqlalchemy/-/AQejNE70FEYJ. 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/sqlalchemy?hl=en.
