[Zope-DB] dco2 and bind variables

[Jim Abramson]

>Ideally, I'd like to pass the zope database connection object to the external method, let the method call execute/fetchall, and return the results, because sometimes the same sql is run against different connections. A few quick tests of this worked just fine, hooray. But does it introduce any risk, as far as the pooling of connections or handling of transactions that may be going on elsewhere in zope? Is there some pitfall I'm not aware of here? It almost seems, well, too easy...
>
>Thanks for advice.
>Jim
>
>  
>


>If you grab the connection object from Zope and call it, you get an 
>object back that has a query() method on it.  You can look under the 
>covers and see that it has a "cursor" attribute, which is a DCOracle2 
>cursor.  If you grab a cursor in this way, the cursor will be registered 
>with the transaction environment in Zope, and you don't need to worry 
>about explicitly committing or rolling back your SQL.

Great news.

>Note that in my opinion, it would be advantageous to expand Zope's 
>notion of what methods a database adapter provides to include providing 
>a DBAPI wrapper object.  Right now the DA connection object's callable 
>result only provides "query()" and a few other methods like __str__.

I'm definitely with you on that. Generally I think Zope could stand to make the power of the objects under 
the hood a little more accessible. This case is a good example. Having to use Products or External Methods, 
in order to get true control over the database interaction, is going to be a drag...since it means a two-pronged 
version control situation (as if version control wasn't already a bit of a headache with Zope). It seems like 
there's so much acrobatics involved to get at the good stuff.

Jim


-- 
Matt Kromer
Zope Corporation  http://www.zope.com/