Sat, 29 Sep 2001 17:27:10 -0700
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).
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
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
- 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??