[ZCM] [ZC] 556/ 3 Comment "sqlvar inconsistency"

[Collector: Zope Bugs, Features, and Patches ...]

Issue #556 Update (Comment) "sqlvar inconsistency"
 Status Pending, Zope/feature+solution medium
To followup, visit:
  http://www.zope.org/Collectors/Zope/556

==============================================================
= Comment - Entry #3 by tino on Jul 21, 2005 4:07 am

+1 for the patch 

I think if the expression works and returns None, it should map to null 

If the keyword "optional" is set, it can still work as it used to,
which - looking at 2.8 source - looks like it just does

if value: return somequoting(value)
else: return 'null'

which results in 0, "", [] ... all mapped to null.
I guess this is coming from the web form approach where every 
object is a string at least.

After all, the attached patch would not apply to the 2.8 version.

There are still some other quirks in this code, for example
ValueError() on missing input variables, where python functions
rather issue TypeError or KeyError.



________________________________________
= Comment - Entry #2 by sabaini on Feb 1, 2005 8:39 am

I'd like to second this. A colleague of mine has just been bitten by this and its really non-intuitive that Nones become NULLs, except if its a string where you have to pass an empty string to get a NULL.

By the same logic one should have to pass 0 for integer params to get NULLs...

________________________________________
= Request - Entry #1 by d.maurer on Sep 3, 2002 4:15 am


Uploaded:  "sqlvar.pat"
 - http://www.zope.org/Collectors/Zope/556/sqlvar.pat/view
The Zope database adapters map SQL NULL to Python None. To be consistent, sqlvar should reverse this
map, i.e. map Python None to SQL NULL for all types
and independent of "optional" (not completely sure
about this "independent of").
==============================================================