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 ? In the development world I've always lived in, we just don't have third party libraries that bring in their own sub-schemas. Up until now the thinking has been, if it's significant enough that it is part of your datamodel, it's part of what you should own yourself, though certainly drawing upon past recipes. For me to understand the use case of stucco_evolution I think I first need to see the light on the use case of these third party apps, which so far seem vague to me. On Apr 19, 2012, at 9:14 AM, Daniel Holth wrote: > stucco_evolution 0.4 has been released. It is a migration tool for SQLAlchemy > that attempts to deal with packaged dependencies having their own migration > scripts. Reading -> as "depends on", > > web application -> openid package -> users/groups package > web application -> users/groups package > > When asked to upgrade web application, stucco_evolution will topologically > sort its dependencies, run all the migrations for the users/groups package, > then run the migrations for the openid package, and finally run the > migrations for the web application. If the dependency migrations are > constrained in what they change, it works. Foreign key relationships can > point in the direction of the -> without problems. > > Let me know if you've tried it, or know of another package that attempts to > deal with non-monolithic database migration. > > -- > 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/-/D_bztOahVBQJ. > 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.
