> > 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. > > that it is, and the surprise here is....repoze.evolution ! yikes ! > > so I guess with these two systems, writing the "scripts" is totally up to > the developer, is that right ? > > There's a lot that alembic could bring into this. There's all the > Alembic ops and dialect-agnostic directives (DDL abstraction). There's > migration modes that either talk directly to a database or generate a SQL > Script. There's the tools to create new scripts and a more sophisticated > versioning scheme too (repoze.evolution seems to use an incrementing > integer). > > It almost seems like Alembic could integrate with repoze.evolution though > I'm not sure if that's useful. You could certainly use Alembic's DDL > abstractions directly in this system with a couple of lines if nothing else? >
My little project doesn't care about DDL, it just passes your script a connection. I didn't consider Alembic when I wrote stucco_evolution in 2010 but I wouldn't mind using it now. At the time I just needed something that didn't scare me. repoze.evolution is fine, it is only 98 lines of code, 17 of which I actually execute. Its design abstracts out the kind of thing that is being upgraded, so you could write another kind of EvolutionManager() to upgrade filesystems if you felt like it. -- 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/-/25sv7PEmPy8J. 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.
