[DB-SIG] Controlling return types, again

Carsten Haese carsten at uniqsys.com
Tue May 22 02:01:23 CEST 2007


On Mon, 2007-05-21 at 16:46 -0500, Carl Karsten wrote:
> I have been following this on and off.  I don't have much to add to the specific
> problem, but I do have some general thoughts that may help.
> 
> I.
> It seems to be a similar (not same, and even similar may be a stretch) problem
> to the parameter formating problem 'solved' by .paramstyle which is one of the
> worst solutions I have seen to any problem :)    to me, the parameter problem
> should be solved "in" the db-api layer, not above it (assuming application is
> above database.)   Again, I agree that the type problem is not the same as
> parameter, so it may need a different solution that will have similarities to
> what I dislike about .paramstyle.

I'm not sure exactly what you mean here. paramstyle fulfills its
function of giving the API implementor enough freedom to get the job
done and letting the application developer know which option the
implementor chose. Now, IMHO format and pyformat paramstyles are an
abomination that should disappear from future versions of DB-API, and
qmark should be the mandatory minimum, but I digress.

My outputmap/inputmap proposal is built with flexibility in mind. Maybe
that's what's bothering you, I don't know.

> II. (going out on a limb here...)
> A user defined data type is used (therefor defined) by the application, so it
> makes perfect sense that the app layer would have implementation details.  If
> the person defining the datatype wants to use it across applications, then they
> will code an appropriate class.   I can't see how a user defined anything can be
> handled generically.

Of course. Informix Dynamic Server allows user-defined types, which is
precisely why my outputmap/inputmap mechanism is flexible enough to
handle a lot of different use case scenarios. But it also provides a
foundation for handling common use cases with standard typemaps that
have database-independent names and agreed-upon semantics. 

Best regards,

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




More information about the DB-SIG mailing list