Am Mittwoch 03 September 2008 15:14:22 schrieb Martijn Faassen:
> Hey Hermann,
> Hermann Himmelbauer wrote:
> > In my current SQLAlchemy / Zope-based design, I need the following:
> > - SQLAlchemy table definitions
> > - classes + mappers
> > - Zope interfaces
> > The problem with this design is that much data has to be defined twice,
> > e.g. the datatype "varchar(50)" should be represented by an interface
> > with TextLine(max_length="50"). Moreover, any changes such as adding
> > columns etc. also have to be done in the interface and the table
> > definition.
> > To overcome this, I just had the idea to use the interface/schema
> > definitions for the table definition itself. Probably I'm not the first
> > who had this idea, but I'm not aware of such an extension to interfaces.
> > Any thoughts on this?
> I'm quite interested in reducing duplication myself.
> I believe z3c.dobbin is an approach in this direction, though it may be
> more ambitious than you need; I believe it tries to make RDB-backed
> objects feel like the ZODB.
I see - I did not look at z3c.dobbin at this point, however, as you already
guessed, my ambition is not to make objects feel like the ZODB.
> In megrok.rdb we've sketched out the reverse of your approach: derive
> the Zope 3 schemas from the SQLAlchemy table definitions. This because
> it's more easy to derive a basic schema from a table definition without
> supplementary information than the other way.
Yes, I also thought about this, but I'm not quite sure about this approach for
the following reasons:
- More schema types than SQL data types, for instance Text, TextLine, Email,
etc. would all match a varchar.
- Constraints like min_length and values (in Choice) are not covered in the
- In my mappers, I often have custom properties (e.g. for converting database
values), which probably can not automatically be included in the schema.
- In the design process, I think the first step is to define the interface.
And the next step is the mapping of the interface (if it's a content object)
to the underlying storage. For that reason, the interface->SA-Table approach
seems more appealing to me.
I know, the interface->dbtable way does also have it's shortcomings and other
things will not be covered by them (e.g. BLOB and varchar can both be
represented by a Text etc.), but I assume that it would be easier to overcome
> (I fear though that as soon as a form needs to be made that *really*
> works properly, supplementation of the conversion process with more
> detailed schema information is still necessary. We have been thinking
> about good ways to express this)
Yes, for the SA-Tables -> schema approach, certainly.
> I believe that ore.alchemist or somesuch also implements this approach.
> This has been factored out by Laurence Rowe in something called
> collective.mercury. This code is more mature than megrok.rdb's
> conversion code, though in my opinion also a bit more complicated than
> it might be.
That's interesting and I'll have a look at it, although I'm not really
convinced about the SA-Tables -> schema approach.
Thanks for your comments!
GPG key ID: 299893C7 (on keyservers)
FP: 0124 2584 8809 EF2A DBF9 4902 64B4 D16B 2998 93C7
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -