Re: [Zope-dev] Idea: Create SQL-Alchemy tables via interfaces
On Wed, Sep 03, 2008 at 05:18:50PM +0200, Hermann Himmelbauer wrote: Am Mittwoch 03 September 2008 16:02:17 schrieb Brian Sutherland: On Wed, Sep 03, 2008 at 02:43:31PM +0200, Hermann Himmelbauer wrote: Hi, 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 much more in favour of the reverse procedure. I think the database is the canonical store of this information and that SQLAlchemy should read that and make it available for doing form validation. But isn't exactly that the real meaning of interfaces? So I have the impression that at the beginning of the design process, I'd model the interfaces, which describe and express everything I expect from the underlying objects. And when that is done, I'd program the underlying objects. And for content objects, the storage could be in an RDB (SQLAlchemy), or somewhere else. And for that, the table structure could be derived from the interface. Trying to derive an RDB table structure from an object model's design has nearly always left me with badly designed and/or badly performing database tables. Every time, it's paid me to design the database structure to be application independent. Basically assume that your application will never be the only application using the database. Many projects have a way of sprawling and having a database usable by non-application code is a big advantage. So, given that I believe the above, trying to use the application to create an application independent database schema is the wrong way around. If I model it the other way round, the power of interfaces is somehow crippled: - The tables can already be documented in the table declaration itself, so the interfaces are only useful for extra documentation, such as mapper properties and class properties. - The interface values are of mediocre value for forms, too, as the forms will often need a change of the schema. (E.g. think of an add person form, where the name is required and in comparison a search form, where the name may not be required and thus the name-schema cannot be 1:1 used, or, even simpler, think of a change of the title). I currently either copy the schemas into my form, or even write separate interfaces. - The real reason I need the interfaces is that I have to include them in my configure.zcml in order to make the underlying objects read/writeable. But this is in my case only annoying, but not helpful at all. Best Regards, Hermann -- [EMAIL PROTECTED] GPG key ID: 299893C7 (on keyservers) FP: 0124 2584 8809 EF2A DBF9 4902 64B4 D16B 2998 93C7 -- Brian Sutherland ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Idea: Create SQL-Alchemy tables via interfaces
Am Donnerstag 04 September 2008 09:10:22 schrieb Brian Sutherland: On Wed, Sep 03, 2008 at 05:18:50PM +0200, Hermann Himmelbauer wrote: Am Mittwoch 03 September 2008 16:02:17 schrieb Brian Sutherland: On Wed, Sep 03, 2008 at 02:43:31PM +0200, Hermann Himmelbauer wrote: Hi, 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 much more in favour of the reverse procedure. I think the database is the canonical store of this information and that SQLAlchemy should read that and make it available for doing form validation. But isn't exactly that the real meaning of interfaces? So I have the impression that at the beginning of the design process, I'd model the interfaces, which describe and express everything I expect from the underlying objects. And when that is done, I'd program the underlying objects. And for content objects, the storage could be in an RDB (SQLAlchemy), or somewhere else. And for that, the table structure could be derived from the interface. Trying to derive an RDB table structure from an object model's design has nearly always left me with badly designed and/or badly performing database tables. Every time, it's paid me to design the database structure to be application independent. Basically assume that your application will never be the only application using the database. Many projects have a way of sprawling and having a database usable by non-application code is a big advantage. But wouldn't the database still be application independent this way? The only difference seems to be that I'd define the database structure in the interface. And zope.interface is a package that can easily be included in a non-zope.app related application. So, given that I believe the above, trying to use the application to create an application independent database schema is the wrong way around. To be honest, I personally also always went the RDB - Zope way, either because the database already existed, or for some other reasons. Therefore I don't really had such negative experiences, but I expect that there will problems if one has an object-only design and tries to stuff these objects in the database later on. Thanks for you comments; I'm curious if other people see that issue the same way. Best Regards, Hermann -- [EMAIL PROTECTED] GPG key ID: 299893C7 (on keyservers) FP: 0124 2584 8809 EF2A DBF9 4902 64B4 D16B 2998 93C7 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Idea: Create SQL-Alchemy tables via interfaces
Hermann Himmelbauer wrote: [snip] - The real reason I need the interfaces is that I have to include them in my configure.zcml in order to make the underlying objects read/writeable. But this is in my case only annoying, but not helpful at all. Ah, interesting! This is a problem that doesn't exist in Grok, as we turn off model-based security checks. (views still make them, and permissions can still be model based. just no automatic checks when you access a method or attribute) Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Idea: Create SQL-Alchemy tables via interfaces
Hi, 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? Best Regards, Hermann -- [EMAIL PROTECTED] GPG key ID: 299893C7 (on keyservers) FP: 0124 2584 8809 EF2A DBF9 4902 64B4 D16B 2998 93C7 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Idea: Create SQL-Alchemy tables via interfaces
You may wish to look at z3c.dobbin, though the issue I have found in my own experimentation, is with association tables for many to many relationships which throws in a wrench into this otherwise elegant solution. There may be something to around this in future. Hermann Himmelbauer wrote: Hi, 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? Best Regards, Hermann ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Idea: Create SQL-Alchemy tables via interfaces
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. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Idea: Create SQL-Alchemy tables via interfaces
Hi Hermann, I'm currently using ore.alchemist to map sqlalchemy tables to zope3 schemas. Ok, so I had to tweak a couple of stuff but the end result is that I have objects which are mapped to rdbms tables via sqlalchemy and I can use generic formlib forms which decreases my development time for new features. So my advice is checkout alchemist and ore.alchemist, it worked for me. Regards Francois Lubbe PS: the reason I had to tweak stuff is because I'm migrating from ZPatterns on Zope 2.7.8 to ore.alchemy/sqlalchemy on Zope 2.10.4 and I needed to have both Zpatterns and ore.alchemy running on the same instance as migrating everything at once was not a viable option. David Pratt wrote: You may wish to look at z3c.dobbin, though the issue I have found in my own experimentation, is with association tables for many to many relationships which throws in a wrench into this otherwise elegant solution. There may be something to around this in future. Hermann Himmelbauer wrote: Hi, 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? Best Regards, Hermann ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Idea: Create SQL-Alchemy tables via interfaces
On Wed, Sep 03, 2008 at 02:43:31PM +0200, Hermann Himmelbauer wrote: Hi, 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 much more in favour of the reverse procedure. I think the database is the canonical store of this information and that SQLAlchemy should read that and make it available for doing form validation. Best Regards, Hermann -- [EMAIL PROTECTED] GPG key ID: 299893C7 (on keyservers) FP: 0124 2584 8809 EF2A DBF9 4902 64B4 D16B 2998 93C7 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope ) -- Brian Sutherland ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Idea: Create SQL-Alchemy tables via interfaces
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 database - 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 them. (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! Best Regards, Hermann -- [EMAIL PROTECTED] GPG key ID: 299893C7 (on keyservers) FP: 0124 2584 8809 EF2A DBF9 4902 64B4 D16B 2998 93C7 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Idea: Create SQL-Alchemy tables via interfaces
Am Mittwoch 03 September 2008 16:02:17 schrieb Brian Sutherland: On Wed, Sep 03, 2008 at 02:43:31PM +0200, Hermann Himmelbauer wrote: Hi, 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 much more in favour of the reverse procedure. I think the database is the canonical store of this information and that SQLAlchemy should read that and make it available for doing form validation. But isn't exactly that the real meaning of interfaces? So I have the impression that at the beginning of the design process, I'd model the interfaces, which describe and express everything I expect from the underlying objects. And when that is done, I'd program the underlying objects. And for content objects, the storage could be in an RDB (SQLAlchemy), or somewhere else. And for that, the table structure could be derived from the interface. If I model it the other way round, the power of interfaces is somehow crippled: - The tables can already be documented in the table declaration itself, so the interfaces are only useful for extra documentation, such as mapper properties and class properties. - The interface values are of mediocre value for forms, too, as the forms will often need a change of the schema. (E.g. think of an add person form, where the name is required and in comparison a search form, where the name may not be required and thus the name-schema cannot be 1:1 used, or, even simpler, think of a change of the title). I currently either copy the schemas into my form, or even write separate interfaces. - The real reason I need the interfaces is that I have to include them in my configure.zcml in order to make the underlying objects read/writeable. But this is in my case only annoying, but not helpful at all. Best Regards, Hermann -- [EMAIL PROTECTED] GPG key ID: 299893C7 (on keyservers) FP: 0124 2584 8809 EF2A DBF9 4902 64B4 D16B 2998 93C7 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Idea: Create SQL-Alchemy tables via interfaces
Hi there, On Wed, Sep 3, 2008 at 4:34 PM, Hermann Himmelbauer [EMAIL PROTECTED] wrote: [snip] 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 database Yes, true. But table descriptions need foreign key information, and possibly you need table creation arguments. How would you deal with relations? I guess those aren't part of the table description, but would you want to express them in your schema? . - In my mappers, I often have custom properties (e.g. for converting database values), which probably can not automatically be included in the schema. I don't think I understand this bit. Could you elaborate? - 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'd argue that if you are going to store your data in a relational database, the first step may very well be the design of the actual database, not the interface. If you really first want to think about python object interfaces only, why not simply use the ZODB then? 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 them. My impression was the other way around: I find more fundamental concepts missing in schemas that are needed for relational database description than the other way around. Foreign keys, some uniqueness constraints and indexes are (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. Well, for schema - SA-Tables you'd need to supplement the schema with relational database information, somehow find ways to express various relational database concepts in Zope 3 schema.. invent something SQLAlchemy already can do.. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Idea: Create SQL-Alchemy tables via interfaces
Am Mittwoch 03 September 2008 17:30:23 schrieb Martijn Faassen: Hi there, On Wed, Sep 3, 2008 at 4:34 PM, Hermann Himmelbauer [EMAIL PROTECTED] wrote: [snip] 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 database Yes, true. But table descriptions need foreign key information, and possibly you need table creation arguments. How would you deal with relations? I guess those aren't part of the table description, but would you want to express them in your schema? . Hmmm, I'm thinking about something like List(Objects) here. (Don't know the exact schema syntax). Thing is, that most often, if I have a relation, I also have a mapper that represents this relation. And that mapper will be either an object (1:1, 1:n), or a list (n:1, n:n). And yes, I'd probably define extra schema attributes, perhaps by creating a mixin for schema fields (class SATextLine(TextLine, SASchema)) that extends the schema syntax. - In my mappers, I often have custom properties (e.g. for converting database values), which probably can not automatically be included in the schema. I don't think I understand this bit. Could you elaborate? For instance, in one of my databases emails are splitted and the username/hostname part is stored seperately for some reason. However, in my form I'd rather want one field, therefore I have some property that splits/combines this value and stores/reads it on/from the username/hostname part. - 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'd argue that if you are going to store your data in a relational database, the first step may very well be the design of the actual database, not the interface. If you really first want to think about python object interfaces only, why not simply use the ZODB then? I do use and like ZODB, but it does not scale well for write operations, indexing is complicated, relations can not be easily implemented, all in all simply inappropriate for many applications. Although ZODB may not be useable for a specific case, why not use a Zope3-style design process? So I'd start out with interfaces that describe my content objects, then I'd model relations, with interfaces too. And when I'm done, I'd derive the SQLAlchemy tables from that. But, you know, that's theory, you may be right that this approach is not possible. 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 them. My impression was the other way around: I find more fundamental concepts missing in schemas that are needed for relational database description than the other way around. Foreign keys, some uniqueness constraints and indexes are Yes, true. Interfaces would have to be extended to cover that. But that should be possible, I assume. (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. Well, for schema - SA-Tables you'd need to supplement the schema with relational database information, somehow find ways to express various relational database concepts in Zope 3 schema.. invent something SQLAlchemy already can do.. Yes, that's certainly a challenge. Nevertheless this would give interfaces the value they preserve, because at this state, I think, interfaces for SA-Tables are to some degree obsolete (see my other mail). Best Regards, Hermann -- [EMAIL PROTECTED] GPG key ID: 299893C7 (on keyservers) FP: 0124 2584 8809 EF2A DBF9 4902 64B4 D16B 2998 93C7 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
