[Zope3-Users] Can interfaces be mutated cleanly?

[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 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.

Best Regards,
Hermann 

-- 
x1 at aon.at
GPG key ID: 299893C7 (on keyservers)
FP: 0124 2584 8809 EF2A DBF9  4902 64B4 D16B 2998 93C7