On 2008-01-23 14:11, Stuart Bishop wrote:
> M.-A. Lemburg wrote:
>> So we do need to store the "formatID" as well ?
>
> It looks like yes we do. MySQL's syntax for xids allows an optional formatid
> and this is returned by XA RECOVER. In MySQL, it is a number rather than a
> string. Assuming that any system that uses more than a simple string for the
> xid is doing so to map onto the XA specification, we could safely represent
> xids as a 3-tuple of (unicode, unicode, integer).
>
> How to deal with None's and empty strings needs to be thought out though to
> avoid round trip edge cases:
>
>>>> con = connect('')
>>>> xid = ('g', '', None)
>>>> con.tpc_begin(xid)
>>>> con.tpc_prepare()
>>>> con.tpc_recover()
> [('g', None, 1)]
>>>> con.tpc_recover()[0] == xid
> False
>
> '' and None for the gtid and brid would be equivalent, and 1 and None would
> be equivalent for the format_id (1 is the default format id in MySQL). To
> avoid round trip issues with tuples, only one of these values should be
> allowed.
>
> If we use an object, these issues go away:
I'm not sure I understand... a tuple *is* an object after all :-)
Why does '' get converted to None on output ?
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 ?
>>>> con = connect('')
>>>> xid = Xid('g', '')
>>>> tuple(xid)
> ('g', None, 1)
>>>> con.tpc_begin(xid)
>>>> con.tpc_prepare()
>>>> con.tpc_recover()
> [<Xid 'g', None, 1>]
>>>> con.tpc_recover()[0] == xid
> True
>
>> Given that the formatID is used for some purpose as well (probably
>> just as identification of the TM itself), I guess we'd have
>> to use a 3-tuple (format id, global transaction id, branch id).
>>
>> Modules should only expect to find an object that behaves like
>> a 3-sequence, they should accept whatever object is passed to
>> them and return it for the recover method.
>>
>> This leaves the door open for extensions used by the TM for XID
>> objects.
>
> I don't see a technical problem with the tuple apart from the round tripping
> issue above and someone might have a nice solution to that. Subjectively, I
> think an object reads better though, particularly as in many cases you will
> only want to bother specifying one or maybe two of the three parts.
> Xid('foo') vs. ('foo', None, None).
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.
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).
This should leave enough room for the TM.
> Is CamelCase of xid 'Xid' or 'XID' or 'XId' ?
Good question. XID itself is an abbreviation. I tend to
leave those alone and use all-capital-letters for classes.
Note that since the TM will create the XIDs, we don't need
to worry about a method or API to generate them.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Jan 23 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
