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

[Gustavo Niemeyer]

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