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.

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.

(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)

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.

If you want to work on such a package we could start with the tiny bit 
in megrok.rdb and factor it out into a separate package.



Zope-Dev maillist  -  Zope-Dev@zope.org
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope )

Reply via email to