[Zope3-Users] Can interfaces be mutated cleanly?

[Christian Theune]

Hi,

Am Freitag, den 13.04.2007, 08:36 +0200 schrieb Hermann Himmelbauer:
> Am Donnerstag, 12. April 2007 17:22 schrieb Christian Theune:
> > Hi,
> >
> > I didn't find anything in the documentation or google on this:
> >
> > I want to define an interface like:
> >
> > class IMySchema(zope.interface.Interface):
> >    pass
> >
> > Later, I want to use ore.alchemist which currently is able to take a
> > SQLAlchemy table description and turn it into a new interface/schema.
> 
> Interesting - is ore.alchemist the package developed by Kapil Thangalevu? If 
> yes, is it working? I had the impression that the project is abandoned.
> 
> I currently use z3c.zalchemy, which has, however no automatic generation of 
> interfaces.

I use z3c.zalchemy for the transaction integration and only the mapping
code from alchemist. This is "accidental" as I started out with
z3c.zalchemy and only needed the additional mapping. The code is
reasonably split up into modules that allows only using the mapping code
and nothing else.

> > I want to extend this code so that I can pass it an existing interface
> > to modify it (update) with the schema definition.
> >
> > I need this so that the interface is:
> >
> > a) present in the code when reading it
> >
> > b) available for ZCML configuration (it's a problem for us right now
> > because the database/SQLAlchemy stuff is setup up a little bit later
> > after executing a couple of ZCML actions)
> 
> This is a concept I was also thinking about but I'm unsure if it would really 
> lead to architectural advantages:
> 
> The DDL statements specify several constraints for the mapped object, such as:
> 
> - Data Type
> - Maximum string length
> - Enumerations (check in)
> - not null/with default
> 
> So it looks at first appealing to directly adopt them in the object's 
> interface. However, there may be two caveeats:
> 
> 1) Often, the interface definitions are stricter than the DDL-statements. For 
> instance, the database could define a varchar(40), while in the interface, 
> I'd rather limit the schema (and therefore an input field) to a length of 20. 
> Or maybe I'd like to use a more specific datatype which can not be 
> automatically deduced from the DDL-statements
> 
> 2) All ends up with constraints in different locations - some are in the DDL 
> statements, others are in the interfaces. So maybe this also leads to 
> redundancy and complexity. Moreover, what happens if the DDL and interfaces 
> are not being maintained by the same developer group? What if the database 
> guys choose to extend some varchar from 40 to 400, a change which possibly 
> propagates to the page layout? (longer input widget). 
> 
> Therefore maybe it's cleaner to define everything in the interface of the 
> mapped object, regardless if this information is redundant. And then I'm 
> thinking about some check function that tests if the DDL-statements and the 
> interface definitions are conflicting or not - much like with interfaces, 
> which only have contracts with objects (via implements()) and provide 
> utilities such as "verifyObject" to check if they comply.

My motivation is to support agile development sufficiently to start out
with an existing database (that the customer already has) and gradually
move to manually defined schemata in the interface.

Christian

-- 
gocept gmbh & co. kg - forsterstraße 29 - 06112 halle/saale - germany
www.gocept.com - ct at gocept.com - phone +49 345 122 9889 7 -
fax +49 345 122 9889 1 - zope and plone consulting and development
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
Url : http://mail.zope.org/pipermail/zope3-users/attachments/20070414/6c20d1c8/attachment.bin