Aqueduct (Was Re: [Zope-dev] Oracle Database Connection objects dont close)

[Matthew T. Kromer]

alan runyan wrote:

>this is a follow up.  I just tried to close my Oracle database connection
>object and my ZSQLMethods still use it.  so it appears that Open/Close in
>the DCOracle2 beta5.zip dont work.
>
>Zope2.4, DCOracle2 beta5.zip, WindowsNT
>
>should I post this to the DCOracle tracker or to the Collector?
>
>~runyaga
>

This is a misfeature in Aqueduct, AFIAK, where "closed" connections are 
automatically reopened on demand by the application.  There is no 
"administratively closed" state.  If, at some point in time, I get 
*REALLY MAD* at Aqueduct (enough to actually start attacking it) I may 
attempt to address this by letting connections have more than a binary 
state of open/closed -- more like:

                     Administrative State
                     'enabled'        'disabled'
Connection State            
     "connected"       UP              OFF
     "disconnected"    ON              DOWN   

That way, you could have the connection be "on" and have it be 
automatically connected when required.  (Note that that grid isn't 
perfect -- how you can be connected and disabled and call it "OFF" is a 
misnomer, but it represents a transit to the "DOWN" state).

The big gotcha with things like Aqueduct is that it isn't at all 
required that the core class have certain methods which get invoked to 
manage connection state -- because the core class is subclassed by each 
connection type.  So it is not necessarily easy to retrofit new behavior 
without having to touch all known instances of products which subclass 
it -- not a pleasant prospect.  

I'm in favor of trying to split Aqueduct into halves -- one which 
provides core RDBMS connection support and one which provides the useful 
report stuff, and attempting to provide updated guidelines for making 
RDBMS adapters to Zope.  In particular, I'd love to see more 
query-builder type things available, which would require some 
rudimentary discovery mechanisms -- some of which are already there (ie 
the table browser).  The core splitting shouldn't be too bad, but there 
may be a lot more gotchas in trying to provide a migration path.

Anyway, this is all more "wouldn't it be nice if..." rather than any 
concrete action plan.