[DB-SIG] Controlling return types, again

[Art Protin]

Dear folks,
    Carl Karsten wrote:

>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.
>
>  
>
Initially I also saw the .paramstyle as providing the implementor too 
much freedom.

However, I chose to take it as a challenge.  In my implementation, 
.paramstyle is not
read-only but read-write and all of the defined styles are accepted.  In 
fact, once I
figured out how to handle the parsing of SQL comments & literals, 
parsing of any
style of parameters was almost trivial (I had to do that parsing in 
Python due to the
nature of our system).  [Actually, I had to add code to block the styles 
"pyformat"
and "format" because my boss agreed with Carsten, although he would have 
preferred
that I removed code.]

In my opinion (which is never as humble as it should be), "qmark" is 
barely adequate;
numeric should be the required minimum.  But now that so many have 
gotten used
to "qmark", it will probably never go away.

I am glad that the spec. [PEP 249] did not require that .paramstyle be 
read-only and
now oppose any attempt to "correct" that oversight.

>>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 at python.org
>http://mail.python.org/mailman/listinfo/db-sig
>  
>
    Thank you all,
    Art Protin


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/db-sig/attachments/20070522/b54c189f/attachment.html