[Zope-DB] wishlist

[kapil thangavelu]

On Friday 21 September 2001 06:30 am, Matthew T. Kromer wrote:
> kapil thangavelu wrote:
> >
> >i was wondering if you would mind sharing whats on your wish list...
>
> Well, my use of the term "wish list" is mostly idiom, but you've covered
> most of the things I'm unhappy with. I also agree with Andy, that I'd
> like to have a very full testing suite for API compliancy.   One wonders
> if opening up the CVS repository will significantly foster growth of
> test suites (my test cases are mostly ad-hoc programs designed to test
> one or two features, not a *validation* suite).
>
> I specifically want to break apart Aqueduct into two components, such
> that DB connection foundations are one piece, but the query generators
> etc are another.   (Aqueduct is Shared.DC.RDBMS).

(s/RDBMS/ZRDB)

i've looked at aqueduct, i'm not really clear on what your referencing in 
terms of splitting. db connections foundation seemed to be localized to 
connection.py and db_dbi.py. the DA.py stuff seems a bit of misnomer as its 
mainly query building and response handling, but the interaction between this 
and the connection seems to be limited to a single function call. 

> In particular, it's probably [way past] time to write a formal API
> description of how it SHOULD work from Zope, not how it DOES work (which
> is more or less "it does what it does").  In particular, this should
> address various issues related to DB discovery, such that product
> authors can write tools to help query generators assemble queries, etc,
> so the end user does not have to be too sophisticated in the knowledge
> of the schema or SQL.   This does not mean that the revised code will
> USE the features, as much as it does that it forms a better foundation.
>
> However, much of the time, this means finding RDBMS abstractions that
> hide nuances of the various underlying implementations, and that is
> often highly problematic.

problematic to say the least.

what do you think of dbobjects in relation to these objectives?

>  I'd like to be able to see session-correlated
> connection pooling, for example -- so you could have a per-user
> connection to the RDBMS (given certain constraints, anyway) rather than
> per-thread.

i like this in the sense of moving connections away from the zodb soley into 
memory for management, ie loosely connected with zodb anchor points, such 
that there isn't nescessarily a n conn objs x n threads = real connections.

some further additions to a wish list

- i think some classification of a method as dml or dql would be useful, both 
in terms of defining proper transaction semantics (actually considering 
stored procs, probably not that useful here unless user defined for dml/dql), 
and for allowing the possible generation of cached type info from a 
cursor.description.

- i'd like to move the rdbms connections to thread local storage instead of 
just stored as attributes of persistent objects, i think this solves the 
problem that technical requirements of zope level 3 da (as defined by 
petrelli's old docs) need to allow different threads to access a cursor 
(sequentially). this would allow any python level2 db module to function as a 
zope level 3 da.

- global caches for sql methods??

cheers

kapil thangavelu