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 > [email protected] > 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 -- storm mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/storm
