On 22/01/2008, M.-A. Lemburg <[EMAIL PROTECTED]> wrote: > Thanks. I like it a lot, except for making the XID an object - this > always appears to be a string in all the backends you've checked and > also in the XA standard, so I'd go for a simple string instead of > an object (those are always lots of work to do at C level).
In at least MySQL and Oracle, the transaction ID appears to be more than just a string: it is structured into three parts: * a format ID * a global transaction ID * a branch qualifier Stuart has made the argument that the format ID is not important for Python, and I tend to agree (or at least I don't know what situations you'd use it). I do see a use for the branch qualifier though. In a distributed transaction, each resource should have a different transaction ID that share a common global transaction ID but separate branch qualifiers. As transaction IDs are global within database clusters for some backends (PostgreSQL, MySQL and probably others), the branch qualifier is necessary if two databases from the cluster are used in the global transaction. I think it is worth making the API such that it is easy to program to best practices. > Regarding the "xa_" prefix, I'm not much attached to it, but since > the interface does indeed look a lot like the XA interface, why not > make that reference ? Stuart's argument is that if the API differs from XA then using the xa_* prefix could be problematic for adapters that want to expose the XA API. As I don't have any experience with using XA, I can't comment one way or the other about this. > It also makes it clear, that the interface > sits on top of the standard DB-API connection API and that those > methods form a unit. Having a common prefix seems sensible. If we don't use xa_*, Federico's suggestion of tpc_* might make sense. > Plus they are currently not in use by any DB-API module, so don't > interfere with existing APIs. So I guess it comes down to the following questions: 1. Are database adapters likely to want to expose more than what is covered by this proposal? 2. Would this proposed API conflict with those extensions? It isn't clear to me that people want to provide a larger API, since the few adapters that have added 2PC support have done so with APIs that are effectively a subset/simplification of this one. James. _______________________________________________ DB-SIG maillist - DB-SIG@python.org http://mail.python.org/mailman/listinfo/db-sig
