On Thu, 2007-05-03 at 15:04 -0400, Art Protin wrote: > First, I believe that nothing returned from a call to > cursor.fetchXXX() > should be of a type bound to the API/interface. I recognize that this > is > a difficult constraint but the values need to usable by some > application > written in Python and may even need to written to a different DBMS. > I see the role of the interface to make the data available in pure > Python > form. (So this argues against the proposal by Carsten Haese, I think.)
I agree, and I have changed my proposal significantly to remove the "welding" of output data to a specific interface. However, I don't agree with the absoluteness of the assertion that "nothing returned from a call to cursor.fetchXXX() should be of a type bound to the API/interface." For example, Smart Blobs from an Informix database wouldn't have any meaning in any other database, so I think it's acceptable that they are returned as objects from the informixdb module. However, as long as the statement is understood to be about standard SQL types, I have no problem with it. > [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. For your database, this might be a tuple of main type and subtype. The application is free to use a mapping that dispatches to an adapter function solely based on the main type and have the adapter branch on the subtype, or use a mapping that uses both pieces of information for making the choice of adapter function. > [export and import functions...] Associating an import function *and* an export function with the database type information is problematic. I don't have a problem with what you call import functions. They seem to serve the same purpose as the adapter functions in the outputmap in revision 2 of my proposal. (Your naming of mapping directions is from the application's point of view, whereas mine is from the database's point of view following the semantics established by the naming for the setinputsizes and setoutputsizes methods.) On the other hand however, coupling an import function with an export function that's looked up based on the database-side type information is not a good idea, for various reasons. In general, when binding parameters to a query, the parameter need not be destined for a database column. Parameters can appear in the WHERE clause of a select statement, and it's not guaranteed that the underlying database has any way of finding out what type of datum should be bound to such a parameter. Also, even if this information were available, the process for binding an application object to, say, a character column would depend very much on what kind of application object it is. A string can be passed on verbatim, a unicode object needs to be encoded, and a Geometry object might need to be translated into OpenGIS Well-Known-Text format. If the export function were looked up based on database type, those three cases would all have to be handled by the same export function, which seems utterly ridiculous to me. It makes much more sense to map input parameters based on the type of Python object that is provided as the parameter value, and that's the inputmap that I'm proposing. That way you get two separate mappings for the symmetric purposes of: * Given a value and type from the database, map it to an application object, and * Given a value and type from the application, map it to a database object. I don't mind supplying information about the database-side type to the adapter functions as optional parameters if this information is available, but determining the export function based on this is in my opinion not feasible for the reasons I stated above. Best regards, -- Carsten Haese http://informixdb.sourceforge.net _______________________________________________ DB-SIG maillist - DB-SIG@python.org http://mail.python.org/mailman/listinfo/db-sig
