[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.
>
Hi,
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.
Christian
More information about the Grok-dev
mailing list