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 _______________________________________________ DB-SIG maillist - DB-SIG@python.org http://mail.python.org/mailman/listinfo/db-sig
