Hi there, I'd like to verify my understanding of connections and transactions - it seems they work differently to DBAPI v2 connections. I'd also like feedback on my proposed solution for a local problem...which needs connections and transactions to behave as per DBAPIv2. Just want to make sure I do things the recommended way.
As I understand SQLObject, the "connection" you get from a call to connectionForURI is a subclass of DBAPI, which in turn is a DBConnection. However, such an animal is not a connection in the sense of a Python DB-API (PEP249) connection. Because - it keeps a pool of connections (the latter being of the PEP249 variety). Moreover, each time SQL is invoked, the invocation potentially happens on a different such connection from the pool. PEP249 Connections are not automatically pooled, and, more importantly (for my application), you can keep a reference to a connection and use it over a period of time to begin, commit or rollback transactions. Basically, everything that should happen in the same transaction should happen on the same connection. Because of the different connections being used by a sqlobject's DBAPI, you cannot handle transactions in the same way as PEP249. Hence the need for the Transaction object in sqlobject. Now, I can't use the Transaction object, because I have only one chance to set a reference to the "connection" used. And I may want to rollback and start a new transaction several times - all using that same reference. Which can be done with PEP249 connections, but not with a sqlobject.Transaction... (because it becomes obsolete) Moreover, I already have an application which deals with connection pooling and threading issues. And it does a lot of transactional stuff for you as well. So, I basically need a "connection" of some kind for use by SQLObjects which behaves (in part) like the connections of PEP249 - then my application will be able to deal with it sensibly. From what I can glean from the SQLObject code, I would have to do the following: (assuming I do it for postgres only - one can generalise) Subclass SimplifiedPGConnection from pgconnection.PostgresConnection. In it, I make sure: - no caching is done, (I assume getting this to work again is another topic) - autoCommit is off - (is there something I need to do to make sure Python objects are strictly per-connection and not shared amongst different connections?) I add the following semantics: - change __init__ to also call makeConnection(), and store that single connection - override getConnection to return that connection - override releaseConnection to do nothing - add transaction methods: begin, commit, rollback. Their implementations can just forward these method calls to the single connection instance it wraps Now, my app (which deals with PEP249 connections) can create a bunch of SimplifiedPGConnections, pool them, etc. When it dishes one such connection out to code that uses SQLObject, such code should just always pass this connection into methods like .get(). Behind the scenes my app can continue to start, rollback and commit transactions on this connection as with other DB-APIv2 compliant connections. There may be another way - to subclass from Transaction and make it possible to re-instate itself (as "clean" transaction) when you call begin() on it after, say, a rollback(). (But that seems a bit unclean in a way.) Do I understand things correctly? Is this a good way of doing what I need? Thanks -Iwan Vosloo
signature.asc
Description: This is a digitally signed message part
------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________ sqlobject-discuss mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss
