Re: [DB-SIG] Two-phase commit API proposal (was Re: Any standard for two phase commit APIs?)

2008-01-22 Thread Stuart Bishop
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

Re: [DB-SIG] Two-phase commit API proposal (was Re: Any standard for two phase commit APIs?)

2008-01-22 Thread Federico Di Gregorio
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) >

Re: [DB-SIG] Two-phase commit API proposal (was Re: Any standard for two phase commit APIs?)

2008-01-22 Thread M.-A. Lemburg
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

Re: [DB-SIG] Two-phase commit API proposal (was Re: Any standard for two phase commit APIs?)

2008-01-22 Thread James Henstridge
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

Re: [DB-SIG] Two-phase commit API proposal (was Re: Any standard for two phase commit APIs?)

2008-01-22 Thread M.-A. Lemburg
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

Re: [DB-SIG] Two-phase commit API proposal (was Re: Any standard for two phase commit APIs?)

2008-01-22 Thread James Henstridge
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

Re: [DB-SIG] Two-phase commit API proposal (was Re: Any standard for two phase commit APIs?)

2008-01-22 Thread Stuart Bishop
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

Re: [DB-SIG] Two-phase commit API proposal (was Re: Any standard for two phase commit APIs?)

2008-01-22 Thread M.-A. Lemburg
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

Re: [DB-SIG] Two-phase commit API proposal (was Re: Any standard for two phase commit APIs?)

2008-01-22 Thread Stuart Bishop
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

Re: [DB-SIG] Two-phase commit API proposal (was Re: Any standard for two phase commit APIs?)

2008-01-22 Thread M.-A. Lemburg
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 >

Re: [DB-SIG] Two-phase commit API proposal (was Re: Any standard for two phase commit APIs?)

2008-01-22 Thread Federico Di Gregorio
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

Re: [DB-SIG] Two-phase commit API proposal (was Re: Any standard for two phase commit APIs?)

2008-01-22 Thread Dieter Maurer
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

Re: [DB-SIG] Two-phase commit API proposal (was Re: Any standard for two phase commit APIs?)

2008-01-22 Thread M.-A. Lemburg
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,

Re: [DB-SIG] Two-phase commit API proposal (was Re: Any standard for two phase commit APIs?)

2008-01-22 Thread M.-A. Lemburg
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

Re: [DB-SIG] Two-phase commit API proposal (was Re: Any standard for two phase commit APIs?)

2008-01-22 Thread Dieter Maurer
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

Re: [DB-SIG] Two-phase commit API proposal (was Re: Any standard for two phase commit APIs?)

2008-01-22 Thread M.-A. Lemburg
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

Re: [DB-SIG] Two-phase commit API proposal (was Re: Any standard for two phase commit APIs?)

2008-01-22 Thread James Henstridge
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

[DB-SIG] PEP 249

2008-01-22 Thread Konjkov Vladimir
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

Re: [DB-SIG] PEP 249

2008-01-22 Thread Carsten Haese
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

Re: [DB-SIG] PEP 249

2008-01-22 Thread James Henstridge
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

[DB-SIG] PEP 249

2008-01-22 Thread Konjkov Vladimir
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

Re: [DB-SIG] PEP 249

2008-01-22 Thread James Henstridge
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