[DB-SIG] Remaining issues with DB API 2.0

[Andy Dustman]

On Wed, 31 Mar 1999, Greg Stein wrote:

> However, I do believe that MySQL can always take a fully-qualified
> date/time and will trim it back as necessary. This implies a single
> constructor.

Apparently not totally true. M-A and I tested this, and if you pass MySQL
a TIMESTAMP with a fractional seconds part, it treats that as an illegal
value and sets it to zero. Nuisance. This is true at least with 3.22.19a.
I have not tested against 19b.

> I would like to see a stated preference for 'numeric', 'named', and/or
> 'pyformat'. They are marginally clearer, and easier to use.

Are there any databases where the parameter marker is actually an option?
I suppose you could use whatever you wanted for MySQL, but it is vastly
easier to use 'format' and/or 'pyformat'.

> The client should not be required to "escape" the value so that it can
> be used -- the value should be equal to the actual database value."

I.e., the module should do any escaping, correct? If true, I agree.

> I'd say we make two subclasses of Error: InterfaceError, and
> DatabaseError.

Speaking of which, I can't find a obvious way in the Python API to create
an exception with multiple inheritance. Any ideas?

> > > * in all methods that state "an exception is raised..." we should state
> > > *which* exception. We have a complete set defined at the beginning, so
> > > this makes sense to do. I would recommend InterfaceError (it is based on
> > > the interface we provide, rather than the underlying database). Hrm.
> > > Maybe not. I can see a case where the DB module will simply attempt to
> > > call the underlying DB function and generate a DB-related exception.
> > > Thoughts anyone?
> > 
> > This is hard to do, since the types of errors may very well be
> > the whole range of possible Python exceptions + the ones defined
> > in the DB API, e.g. a conversion routine might raise an OverflowError
> > in case of numeric overflow while raising an InterfaceError in
> > case a certain internal assertion failed.
> 
> Good point. I retract my request :-)

This is why I would like to find a way to do multiple inheritance on
exceptions in the Python C API...

> New comment: should we change the globals to be: apiLevel, threadSafety,
> and paramStyle? Or maybe underscore-separated? Or leave them?  hmm... I
> think "Python style" says all lower-case for these, mixed signal on the
> underscore. Thoughts?

My reading of the style guide suggests lower-case, no underscores. 

-- 
Andy Dustman  (ICQ#32922760)    You should always say "spam" and "eggs"
ComStar Communications Corp.                 instead of "foo" and "bar"
(706) 549-7689 | PGP KeyID=0xC72F3F1D   in Python examples. (Mark Lutz)