[DB-SIG] mxODBC and Stored Procedures

[paul@boddie.net]

On Thu, 13 Sep 2001 20:42:33 +0200 "M.-A. Lemburg" <mal@lemburg.com> wrote:
>

[Stored procedures written by other people]

>Ok, ok. You've got me convinced. I'll look into providing support
>for in/out and output parameters too.

Hooray!

Paul wrote:
>> 
>>   (tmp, in_out1, tmp, out1, in_out2, tmp) = cursor.callproc("SOMEPROC",
>>       (in1, in_out1, None, in_out2, in2, in3))
>
>This is what DB API 2.0 specifies if I'm not mistaken.

Sorry! I didn't read it closely enough yesterday. Some might find the above 
notation bizarre, but I think that it's the only way to provide the flexibility 
which would then allow different calling styles to be implemented on top. For 
example, one might want a Parameters object to be passed in and manipulated by 
the stored procedure - this could easily be implemented as a wrapper around the 
above, but the above couldn't be implemented around such an object, I don't 
think.

>Aside: I think that we (pydev) decided to use _ as replacement for unneeded 
>parameters... at least that's what Martin von Loewis uses a lot
>and it seems to work quite nicely.

I thought there was an idiom for this. That sounds like what I've heard before.

[DB-API improvements]

>The 3.0 proposal was really more about a proposal for a DBI wrapper
>around DB API compliant modules. In that sense it did not really
>target the DB API itself.

I think it mutated into that because we didn't think that there were enough 
issues with the existing API. I remember things like parameter syntax and other 
minor things being issues to address with that proposal.

>Which are the issues with DB API 2.0 ?
>
>The only one which comes to my mind is that it would be nice
>to expose the exception objects used by the module on the 
>connection objects as read-only attributes: it makes writing
>generic DB code a lot easier. But this is really only a minor issue,
>something for say DB API 2.1.

Yes, the issue of exception names came up recently on comp.lang.python. On the 
Webware list, a number of people were interested in defining the transaction 
semantics more explicitly; whilst it might be obvious to some people that 
transactions are automatically begun when connections are opened (with most 
systems) even when only SELECT operations are being performed, this fact is 
easily forgotten - in fact, I had forgotten it myself when the topic was 
raised, but it made perfect sense.

In addition to this principly documentation-oriented issue, some people were 
wondering whether explicit transaction demarcation would be possible in the DB-
API. I'm not intimate with the problems that they are trying to solve, but one 
area of interest was database connection pooling.

Paul

-- 
Get your firstname@lastname email for FREE at http://Nameplanet.com/?su