[Zope-DB] Re: [Q] Officially abandon "SQL-null -> Missing.Value mapping"

Matthew T. Kromer matt@zope.com
Mon, 02 Dec 2002 18:20:02 -0500


Dieter Maurer wrote:

>Matthew T. Kromer writes:
> > >I suggest that we officially abandon and deprecate the
> > >"SQL-null" to "Missing.Value" mapping in favour of the much
> > >more usable "SQL-null <-> Python None" mapping.
> > > ...
> > I think the problem is that DTML tends to do a truth test, which None 
> > fails, hence the reason Missing.Value kicks in.
>I do not understand that:
>
>  What "truth test" is DTML doing?
>
> > Certainly most adapters I know of return NULL as None.
>Apparently, we do not need "Missing.Value" then?
>
>  I never read something about a problem for the "SQL null <-> None"
>  mapping, but every once in a while someone has problems
>  with "Missing.Value".
>
>
>Dieter
>  
>
Oops, I thought you were talking about Missing in the sense of <dtml-var 
... missing=> or &dtml.missing-Something;

Missing.Value is a special singleton used by ExtensionClass.  No 
database adapter should *ever* end up returning this singleton for NULL 
answers.

So the big question is why you are getting Missing.Value ever assigned 
to your results.  Do you have any adapter that is doing this?

The alternate problem you MIGHT be having is this:

lib/python/DocumentTemplate/DT_InSV.py does this:

try:
    import Missing
    mv=Missing.Value
except: mv=None

Which means that if the import fails, DTML considers None to be a 
missing value, rather than the special Missing.Value singleton.  If you 
use DTML outside of Zope (where ExtensionClass isnt loaded) this could 
be a problem.  DTML in has always done this though, at least as far back 
as 1998 (the furthest back I can go in CVS).


-- 
Matt Kromer
Zope Corporation  http://www.zope.com/