The problem here seems to be that simple strings should be supported (xid, in the end are simple SQL strings for most backends) while it should be possible to access single parts (format, gtrid, bqual) to play well with the transaction managers. The thing to notice is that even if you mix the two styles, after you compose the parts in the final xid, no two xids can be the same string. So, what about using a 4-tuple?
(full, format, gtrid, bqual) The application layer can pass just the 'full' parameter (a sting) representing the xid directly, or set 'full' to None and let the driver build the string out of the other three parts (and fill 'full' for later reference.) recover() returns a tuple with the 'full' slot always valorized and, if it is possible it also fills the other three slots parsing the xid. This way one has access to the full xid and if it was built from parts to the single parts too. A transaction manager can discover if a recovered() transaction belongs to it by checking the 'format' (it can be None) and there is no need to drop xids from recover() calls. federico -- Federico Di Gregorio http://people.initd.org/fog Debian GNU/Linux Developer [EMAIL PROTECTED] INIT.D Developer [EMAIL PROTECTED] Purtroppo i creazionisti non si sono ancora estinti. -- vodka
signature.asc
Description: Questa รจ una parte del messaggio firmata digitalmente
_______________________________________________ DB-SIG maillist - DB-SIG@python.org http://mail.python.org/mailman/listinfo/db-sig
