[DB-SIG] Controlling return types for DB APIs

[Carsten Haese]

On Mon, 2007-05-07 at 09:53 -0400, Art Protin wrote:
> Database specific information can almost never be handled in a generic
> way
> and what can be made generic should not be tied to types in the API.

We agree on both counts.

> (This opens the question to how to design DBMS specific features in a
> way
> that maximizes transference of training for our users.  Or is that
> what we
> were already working on?)

Yes, I think my type mapping proposal[1] addresses this in an abstract,
generic, and extensible way. An application may need to use a particular
non-standard feature that some, but not all, databases have, and the
application developer still wants to support all databases that have
that particular feature.

In my scenario, the application developer would provide (or reuse
previously provided) database-specific adapter functions to map the
database-specific object into a database-agnostic application-side
object and back, and plug the appropriate functions into the
outputmap/inputmap of the corresponding database connection. The
adapters would be database specific, but the API for registering the
adapters would be the same across all compliant databases.

[1] For those that are new to this thread, see
http://www.uniqsys.com/~carsten/typemap.html .

> >   
> > > [lengthy discussion of main types and sub types...]
> > >     
> > 
> > In the context of my type mapping proposal, for output mapping it is the
> > API's responsibility to convey enough information in the type key so
> > that the mapping can determine which adapter to call.
> How does this contrast with what I said?

It probably doesn't, I think I'm just summarizing what you said.
 
> Sorry.  Does "have the adapter branch on the subtype" mean that you
> accept
> the need for the type information to be passed as a second argument to
> the
> adapter function?  [Looks like you say that below.]

Yes, that is what I am saying, but the information should be optional,
preferably as a keyword argument with an agreed-upon name. API
implementers should be free not to provide the information, and adapter
functions that are plugged into the map are free to ignore it if it's
provided and should fall back gracefully if the information is not
provided.

> Sorry.  Both the .setinputsizes() and the .setoutputsizes() methods
> are implemented
> identically on my system -- they do nothing.

Same here, but that doesn't change the fact that the semantics of
"input" and "output" are well-established and well-defined in the
context of DB-API 2.

>   Viewing the API from the database
> is wrong in only the most subtle of ways.

The pre-established semantics disagree. I think it's better to stick to
those semantics than to confuse matters by adding another naming
convention such as import/export or fromdb/todb or fromapp/toapp.

Best regards,

-- 
Carsten Haese
http://informixdb.sourceforge.net