Hi there, Some background first:
I'm exploring Storm to use as a relational database integration layer with Grok (http://grok.zope.org). Storm is off at a good start as it has Zope 3 integration provided already, and I know Storm is being used successfully by some large Zope 3 projects. On the longer term, Storm is also be a candidate to become the "default story" for doing relational database integration with Grok. Grok is about providing default ways to do things, as opposed to Zope 3's "here's the toolbox" approach, trying to reach out to beginners and more experienced developers who don't always have time to pick and choose tools by hand. 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. Concerning Zope 3 integration, has anything been done by anyone about integrating Storm's variable/property system with Zope 3 schemas? It 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. 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'm very interested to hearing people's thoughts about all this! Regards, Martijn -- storm mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/storm
