[Grok-dev] Re: STORM howto

Christian Klinger cklinger at novareto.de
Fri Mar 14 09:20:47 EDT 2008

Wichert Akkerman schrieb:
> Previously Martijn Faassen wrote:
>> The other point that bothers me about Storm is that they do not have a 
>> database schema abstraction in Python. It's not possible to generate a 
>> RDB schema from Python. They do not generate "create table" statements 
>> at all.
> SQLAlchemy has that option and it is extremely useful for testing: your
> test fixture can setup a sqlite in-memory database and tell SQLAlchemy
> to create the tables and indexes in something like two lines of code and
> you're off.
>> In addition, I think SQLAlchemy allows introspection of existing
>> databases, which allows for the generation of cool tools as well.
>> Again a schema abstraction is helpful to support this kind of feature.
> That is schema autoload, and it is very practical when you want to get
> started quickly. You tell SQLAlchemy the name of a table and it figures
> out the schema and does all the magic you need automatically.
>> Do you know whether people have done work integrating Zope 3 schema with 
>> SQLAlchemy? I think we need a form of integration there, though I'm not 
>> sure yet what shape this should take.
> collective.mercury has code to do that. See
> http://svn.plone.org/svn/collective.mercury/trunk/collective/mercury/sa2zs.py
> Wichert.


in my opinion there are two usecases:

1. make a quick Prototype:
in this case I found it useful to have things like automatic-table 
creation or database2schema things. But if it´s only a prototype maybe 
it´s easier to use ZODB.

2. working on "normal" Projects:
if I want to write a rdb-based application I want to exactly know
which data-definitions and tables i could use. So I write my
own create-statements for my tables. Or there is a DB-Admin who does
this for me. Often there are already existing databases which doesn´t 
need automatic table creation

Form my perspective the automatic-table and database2schema things are 
in my opinion not so important.


More information about the Grok-dev mailing list