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 -- [EMAIL PROTECTED] GPG key ID: 299893C7 (on keyservers) FP: 0124 2584 8809 EF2A DBF9 4902 64B4 D16B 2998 93C7 _______________________________________________ Zope3-users mailing list [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope3-users