James Henstridge wrote: > On 22/01/2008, Stuart Bishop <[EMAIL PROTECTED]> wrote: >> It seems that the formatID is unnecessary and just a requirement of the XA C >> interface. Also, the xid() method you propose should be camelcase to match >> the other type constructors, so Xid(gtrid, bqual=None) or >> TransactionId(gtrid, bqual=None). If the xa_recover/list_prepared method >> returns TransactionId objects they can contain platform specific information >> too which is great (username, prepared timestamp & database for PostgreSQL >> for instance). > > Well, the DB-API does not actually expose any classes other than the > exceptions. The primary objects you work with are all created by > factory functions/methods:
The camelcase suggestion was to match the other type constructors as documented under "Type Objects & Constructors", such as Date, Time, Timestamp, Binary. > * Connections from module.connect() > * Cursors from connection.cursor() > > I was suggesting that transaction ID objects be created by either a > module.xid() or connection.xid() factory function and not make the > class object part of the API. Sure - the class object doesn't need to be part of the API, but xa_recover needs to return a list of something and the behaviour of those somethings needs to be defined. I imagined that would be an object providing .transaction_id & .branch_qualifier at a minimum, and the driver can add in whatever platform specific attributes or behaviour it wants. The xid objects can't be opaque as a transaction manager needs to be able to filter out the relevant from irrelevant. (From the other threads, I'm happy with tpc_ naming). -- Stuart Bishop <[EMAIL PROTECTED]> http://www.stuartbishop.net/
signature.asc
Description: OpenPGP digital signature
_______________________________________________ DB-SIG maillist - DB-SIG@python.org http://mail.python.org/mailman/listinfo/db-sig
