[Zope-dev] Idea: Create SQL-Alchemy tables via interfaces

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

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
> 
> -- 
> hermann at qwer.tk
> GPG key ID: 299893C7 (on keyservers)
> FP: 0124 2584 8809 EF2A DBF9  4902 64B4 D16B 2998 93C7
> 

-- 
Brian Sutherland