Hello Martijn, > Some background first: (...) > On the longer term, Storm is also be a candidate to become the "default > story" for doing relational database integration with Grok. Grok is (...)
We'll be delighted to see this happening. > Storm looks attractive as it looks smaller and simpler in use than > something like SQLAlchemy, while it still aims high in being easy to > integrate and having high performance features. > > Now as to my questions: > > Looking at Storm I noticed one thing that seems to be missing that other > ORM tools for Python do seem to offer: a way to do table definitions in > Python. Instead in the tutorial direct 'create table' statements are > used. I'd be interesting to hear whether this missing feature is > intentional, and if so, what the reasons behind this decision are. It was really designed this way. I'll try to explain shortly some of the reasons for it. It's important to understand, though, that I'm only explaining the choice. I'm sure automatic schema creation is interesting in a number of cases, and I'm not even against having some kind of support for that in the future, *if* we can come up with a system that won't affect the other design goals significantly. So, basically, we didn't want schema management mixed with the ORM for the following reasons: - Avoiding duplication. On all of the projects we need ORMs for, we have fine tuned schema creation and patching. Any schema management introduced in the ORM itself would be duplicating effort. - Centralization and transparency of schema management. All the objects created in our databases, and how they are created, is seen in a single place. - Flexibility. As much as the layer offered to create the schema is flexible, there are a number of uncommon options in schema management, many times dependent on the database itself, that are needed on serious projects (performance/behavior tweaking). We could, of course, try to implement every single option we needed on the schema layer, but besides this process being an unwanted burden, it also didn't make a lot of sense for us to be simply reinventing a different representation for the schema. - Separation of concerns. Not having to deal with schema management in the ORM makes it simpler, and more focused on its real goal. > Concerning Zope 3 integration, has anything been done by anyone about > integrating Storm's variable/property system with Zope 3 schemas? It (...) No, we haven't seen anything being done about it yet. > would be nice to be able to deduce a schema automatically for a > database-backed class (or perhaps the other way around), so one can use > Zope 3's form system. I'd love to discuss this with others; perhaps > someone has already thought about this topic. That's an interesting point. Zope 3 interfaces are probably more suited to create the schema than the Storm class itself, since their goal is precisely to define rather than implement. I would guess that it's also quite easy to create the Storm properties automatically, if that was wanted. > Grok tries to follow DRY: don't repeat yourself. I can see Grok > integration with Storm to contain some (partial) repetitions: > > * define the table and its columns > > * define the class that represents this table (or more tables) as a > Python object > > * define a Zope 3 schema for the public properties of a class (so edit > and add forms can be generated) > > It's clear that each of these repetitions exist because these are > different things: each serves a special purpose and having these be > separate can make the whole system more flexible - that's typically the > reason there is repetition in Zope 3 components too. That doesn't take > away that there is a lot of repetition here, and it's interesting to > think about ways to reduce this, perhaps by having a definition system > that can do all three at once. I agree with all of these points. I'll be happy to discuss and try to participate somehow if you want to try something like that out. -- Gustavo Niemeyer http://niemeyer.net -- storm mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/storm
