On 2008-01-24 07:05, Stuart Bishop wrote:
> M.-A. Lemburg wrote:
>
>>> If we use an object, these issues go away:
>> I'm not sure I understand... a tuple *is* an object after all :-)
>
> An object we can't define the constructor of.
>
>> Why does '' get converted to None on output ?
>
> Because if, say, on MySQL you do """XA PREPARE 'foo'""", MySQL will fill in
> the branchid and formatid with defaults - in MySQL's case '' and 1
> respectively.
>
>> The database module
>> should not try to change the object in any way (regardless of whether
>> it's a string, tuple, custom sequence like object, etc.). At least
>> that's the theory.
>>
>> Or is this a side-effect of MySQL doing some internal mapping of
>> the tuple contents to some internal table ?
>
> The databases that support XA style xids have to be able to round trip with
> the defined C data structure. This structure is the formatid, the length of
> the global transaction id, the length of the branch id, and an array of
> bytes containing the concatenated ids. In this structure there is no way to
> differentiate a NULL from an empty string or a NULL formatid from whatever
> integer you map NULL to.
>
> I guess validation of the xid could be done by the driver in tpc_begin(),
> tpc_commit(), tpc_rollback() and an exception raised if the driver detects
> that round tripping via the database is not possible.
It is the database module's responsibility to make sure that the
xid can round-trip.
If we restrict the three entries of the xid tuple to be strings,
this should be easily possible by e.g.
* combining the three strings into one and decoding this
combination again in .tpc_recover()
* mapping the components to ids/values that the database
backend can handle and undoing this mapping in .tpc_recover()
* not passing the ids to the database backend at all and
managing the xid at the database module level
>> I think we shouldn't restrict the TM by specifying a particular
>> object. After all, the DB-API is about the RM, not the TM.
>
> I don't follow this. We have to specify what object can be passed to
> tpc_begin and is returned from tpc_recover. The only issue is if it is if we
> force this to be a 3-tuple or whatever the driver decides to return from a
> module level Xid() method.
The important aspect is that the TM must be able to get
back an object that it can compare against whatever
it originally passed to the database module.
Perhaps we could have the TM do something along these
lines:
# From the TM:
xid = conn.xid(fid, gid, bid)
conn.tpc_begin(xid)
conn.tpc_prepare(xid)
...
# See whether there are pending transactions:
xids = conn.tpc_recover()
# Recover only those transactions that the TM has initiated:
for (fid, gid, bid) in xids:
if tm_check_xid(fid, gid, bid):
tm_do_recovery(fid, gid, bid)
>> However, it may be worthwhile to have the RM at least peek
>> into the XID object and that's why I think we should require
>> the XID object to implement the __getitem__ protocol and
>> have the first three positions defined as (format id,
>> global transaction id, branch id).
>
> I wouldn't say 'may be worthwhile'. I'd go for 'is essential'. If you can't
> inspect the results from tpc_recover(), the method is pointless.
Agreed.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Jan 24 2008)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
:::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! ::::
eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
Registered at Amtsgericht Duesseldorf: HRB 46611
_______________________________________________
DB-SIG maillist - DB-SIG@python.org
http://mail.python.org/mailman/listinfo/db-sig
