Carsten Haese wrote: > 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.
to me it gave the API implementor too much freedom for no good reason, other than make it easier by making it the application developers problem. I don't see why one format couldn't have been chosen and all API implementors could work with it, just like all application developers now have to work with it. > > 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. That sounds in line with my thoughts. Carl K _______________________________________________ DB-SIG maillist - DB-SIG@python.org http://mail.python.org/mailman/listinfo/db-sig
