[ZODB-Dev] AdaptableStorage and ZClass instances

[Rocky Burt]

Personally I feel that this would take care of a most common
situations.  But for our specific business need, being able to
completely structure the tables and queries used to insert/select data
from those tables is something we need.

For example, maybe I'd want one object to be split amongst several
tables.

- Rocky (r0ky)


On Thu, 2003-02-13 at 15:21, Roch=C3=A9 Compaan wrote:
> > I've been wondering if it would be possible to blend AdaptableStorag=
e 
> > and "Modeling":
> > 
> > http://modeling.sourceforge.net/
> 
> Don't know this but will have a look.
> 
> > >Jean and Roch=C3=A9 at Upfront had some interesting ideas on how to=
 go about 
> > >'templating' SQL to make this possible, perhaps they could comment?
> > 
> > All the relevant code is in the "gateway_sql" subpackage.  We can 
> > refactor mercilessly, since the tests have decent coverage.
> 
> On first impresssion it doesn't seem to be that hard to take what is
> there and only override it where necessary for use on another RDBMS.
> This is after a quick scan and relative to the amount of work I expect=
ed
> it to be.
> 
> I think object relational mappings are very implementation specific so=
 I
> don't expect the mapper to do all the magic. AdaptableStorage can help
> do the 70% of work that is common in all implemenations.
> 
> What I think will work much better and really improve queryability of
> data is if one uses a table per class map. One shouldn't require a
> gateway per class however - that's to much work ;-) A single gateway
> can generate sql for most classes based simply on class properties.
> What will help here is if one has typemap per RDBMS, mapping python
> datatypes to the RDBMS' datatypes. For more complex types one will nee=
d
> specialised gateways but that is to be expected.
> 
> If this idea have appeal - I have some code that inspects class schema
> and generates sql from it. I'll see if I can make some time this weeke=
nd
> to make it work with AS.