Hey, On Tue, Sep 10, 2013 at 11:00 PM, Jamu Kakar <[email protected]> wrote: > I'm glad you're enjoying Storm! We talked about this years ago and > decided that there are at least two pieces: > > 1. Schema generation/initial creation of a schema for a new database. > The method most of us have used is to always have a current schema.sql > file that defines the schema for a project. It should always be > update and acts as documentation as well as bootstrapping for new > deployments. > > 2. Patches to update live databases. We have a simple system in > storm.schema that can be used to apply patches to a live database and > bring up to the spec defined in schema.sql. There's the obvious > problem that bugs in your patches can introduce skew between live > production systems and what's in schema.sql but we've always lived > with that and it hasn't been a big problem, in practice.
One solution would to initialize new databases using the patch sequence, so the final schema will be always the same. > We've always felt that schema generation, as in from Storm-based > Python classes, was out of scope and instead always thought about > annotating Storm properties in a way that would allow such a system to > be built outside of Storm. I still think that's a good idea. Agreed. The main task with database schema is upgrading them, more than creating, and the ideas in AutomaticSchemaGeneration don't seem to really address that. I believe that storm.schema is good enough and it's been successfully used by a large and long-lived project like Canonical's Landscape. There some documentation in the module docstring of storm/schema/schema.py. Cheers, Free -- storm mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/storm
