[storm] some questions about Storm (from the perspective of Grok)

[Martijn Faassen]

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