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

[Jodok Batlogg]

hello martijn, gustavo - and all others :)

On 13.03.2008, at 17:20, Gustavo Niemeyer wrote:

> 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.

that would be awesome.
we're about to release the lovely.nozodb as ZPL.
basically lovely.nozodb enables to run a zope3 application as wsgi  
application without the need of a zodb storage and without zconfig.  
the results (performance, stability) in combination with storm and  
postgresql are really great.

>> 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.

+1
we at lovely systems don't believe in automatic sql schema generation  
either.

>> 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.

same here.

>> 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.

yes that should be possible. however - i think the engineer should be  
able to create the sql himself. i don't believe in sql autogeneration.  
at least not for our use-cases.
i mean, if we are creating a optimized application we want to define  
the database logic on our own. sql functions, indexes, triggers,...

>> 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.

yes - as you said. these things do different things. and yes - it  
would be nice to have some simplification :)
but usually the application logic is much more work than the content  
type / schema / python class definition.

jodok


>
>
> 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
> storm at lists.canonical.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/storm

--
"Beautiful is better than ugly."
   -- The Zen of Python, by Tim Peters

Jodok Batlogg, Lovely Systems GmbH
Schmelzhütterstraße 26a, 6850 Dornbirn, Austria
mobile: +43 676 5683591, phone: +43 5572 908060