James Henstridge wrote:
> Here is an updated version of the proposal. It removes the analysis
> of the different databases, and updates the proposed API to match what
> we've been discussing here.
I'm happy with the design.
I personally don't think we should use the xa prefix, as this will make
Il giorno mar, 22/01/2008 alle 15.48 +0700, Stuart Bishop ha scritto:
>
> I'm happy with the design.
>
I am very happy too, but..
>
> I would think the following would be better names:
> con.begin_prepared(xid=None)
> con.prepare_transaction()
> con.rollback_prepared(xid=None)
>
On 2008-01-21 15:40, James Henstridge wrote:
> On 21/01/2008, James Henstridge <[EMAIL PROTECTED]> wrote:
>> On 18/01/2008, James Henstridge <[EMAIL PROTECTED]> wrote:
>>> So is there any recommendations for what a two-phase commit API should
>>> look like?
>> I did a bit of investigation into a fe
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
On 2008-01-22 12:33, James Henstridge wrote:
> 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 st
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, bqua
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) o
On 2008-01-22 13:34, Stuart Bishop wrote:
> 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 othe
M.-A. Lemburg wrote:
> It only needs to be defined in the context of the module exposing
> that recover API, since you'd only pass it back to the methods of
> that same API.
>
> We could just describe the transaction id as object in the spec and
> then have the modules decide what type this maps
On 2008-01-22 14:09, Stuart Bishop wrote:
> M.-A. Lemburg wrote:
>
>> It only needs to be defined in the context of the module exposing
>> that recover API, since you'd only pass it back to the methods of
>> that same API.
>>
>> We could just describe the transaction id as object in the spec and
>
Il giorno mar, 22/01/2008 alle 14.23 +0100, M.-A. Lemburg ha scritto:
> Since there are only two id components that appear to be relevant,
> how about using a 2-tuple for the transaction id ?
...and modules that want to use a custom object can always implement the
tuple interface and stay compati
M.-A. Lemburg wrote at 2008-1-22 13:42 +0100:
> ...
>We could just describe the transaction id as object in the spec and
>then have the modules decide what type this maps to, e.g. one module
>might want to use a tuple (or even namedtuple) for this, another
>might not want to bother at all and use t
On 2008-01-22 19:52, Dieter Maurer wrote:
> M.-A. Lemburg wrote at 2008-1-22 13:42 +0100:
>> ...
>> We could just describe the transaction id as object in the spec and
>> then have the modules decide what type this maps to, e.g. one module
>> might want to use a tuple (or even namedtuple) for this,
On 2008-01-22 19:48, Dieter Maurer wrote:
> James Henstridge wrote at 2008-1-22 20:33 +0900:
>> ...
>> I do see a use for the branch qualifier though. In a distributed
>> transaction, each resource should have a different transaction ID
>
> Why?
> Why is it not equally good to use a common transa
M.-A. Lemburg wrote at 2008-1-22 20:31 +0100:
> ...
>Branch ids are used for e.g. multiple connections of the same RM
>engaging in a global transaction. Each of those connections gets
>its own branch id.
But using multiple connections to the same RM seems to
be an error in the first place.
Assu
On 2008-01-22 20:54, Dieter Maurer wrote:
> M.-A. Lemburg wrote at 2008-1-22 20:31 +0100:
>> ...
>> Branch ids are used for e.g. multiple connections of the same RM
>> engaging in a global transaction. Each of those connections gets
>> its own branch id.
>
> But using multiple connections to the s
On 22/01/2008, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
> On 2008-01-22 12:33, James Henstridge wrote:
> > 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 c
in definition of
.execute(operation[,parameters])
.
A reference to the operation will be retained by the
cursor. If the same operation object is passed in again,
then the cursor can optimize its behavior.
What meens "the same operation object is passed in again"?
There's no definition for Clas
On Wed, 2008-01-23 at 10:12 +0700, Konjkov Vladimir wrote:
> in definition of
> .execute(operation[,parameters])
> .
> A reference to the operation will be retained by the
> cursor. If the same operation object is passed in again,
> then the cursor can optimize its behavior.
>
>
> What meens
On 23/01/2008, Konjkov Vladimir <[EMAIL PROTECTED]> wrote:
> in definition of
> .execute(operation[,parameters])
> .
> A reference to the operation will be retained by the
> cursor. If the same operation object is passed in again,
> then the cursor can optimize its behavior.
The operation obje
When I'm implementin on C my Python module that are used to access
ODBC 2.0 database, I can't found description in PEP-0249 about the
case when one .executeXXX follows another on the same cursor object.
I think that after .executeXXX cursor can only be
fetchedXXX or closed. Reexecution permited an
On 23/01/2008, Konjkov Vladimir <[EMAIL PROTECTED]> wrote:
> When I'm implementin on C my Python module that are used to access
> ODBC 2.0 database, I can't found description in PEP-0249 about the
> case when one .executeXXX follows another on the same cursor object.
>
> I think that after .exec
22 matches
Mail list logo