[DB-SIG] Re: db module wrapper

[Randall Smith]

Thanks for the test suite reference.  It should help out allot.  We have 
set up on sourceforge at

http://sourceforge.net/projects/pydal/

Our work is in CVS and we have a feeble working implementation.  You can 
download in from cvs.

cvs -d:pserver:anonymous at cvs.sf.net:/cvsroot/pydal checkout dal

We could use some testing and feedback.  Thanks.

Randall

Stuart Bishop wrote:
> 
> On 25/08/2004, at 1:20 AM, Randall Smith wrote:
> 
>> M.-A. Lemburg wrote:
>>
>>> Jonathan M. Franz wrote:
>>>
>>>> Note to Marc: the clarifications as to the descriptor fields and 
>>>> their meanings we discussed on the python list a long time ago was a 
>>>> big help - but those clarifications are still outstanding in the 
>>>> spec itself.  Should I submit a doc patch?
>>>
>>> Yes, please.
>>>
>>>>> I'm mainly programming to API 2.  Config files are used to adapt 
>>>>> modules that do not completely comply.  In theory, a module that is 
>>>>> API2 compliant needs no config.
>>>>
>>>>
>>>>
>>>> We're pretty much at the same point.  A word of warning - watch out 
>>>> for assumed behaviors.  For example, some modules return the number 
>>>> of rows affected by an execute as the return value of the execute; 
>>>> Others do not.  The standard just states that return values are 
>>>> undefined - hence the ambiguity and different behavior.
>>>
>>> It says "Return values are not defined". You should use .rowcount to
>>> access the number of affected rows. The reason is that getting this
>>> information from the database can be an expensive operation; hence
>>> you don't want to do this for every single call to .execute().
>>
>> Unless someone suggests otherwise, the wrapper's execute method will 
>> return None.
> 
> 
> If you haven't already, you may want to use the DB-API 2.0 test
> suite at http://zen.freezope.org/Software/DBAPI20TestSuite/ . It
> should happily tell you when your code is broken or when the
> drivers are.
> 
> I think there is definitely a need for your work - it is the sort
> of thing a lot of us have wanted to do, but never gotten around to
> actually doing. Your limited scope (Just DB-API 2.0) is excellent -
> a project that can actually be completed and used as a foundation
> for wackier projects. There is also some support to get this sort
> of thing into Python core (if for no other reason than to counter
> the false idea that "Python doesn't do databases" which many people
> get after seeing no reference to them in the reference manual).
> 
> I'm happy enough to help out if you need extra hands - give me a
> ping if you set up a dev mailing list or sourceforge project.
> 
> --  Stuart Bishop <stuart at stuartbishop.net>
> http://www.stuartbishop.net/