problem with expression: null values in table

[Steve Lime]

I suppose we should start with an inventory of the various ways data providers
represent null values and then devise a scheme to address the problem.

Is using NULL for "NULL" values really that far fetched? Seems like the expression
parser would be the biggest hassle. My guess is that many other portions of the
code that work off item values already test for NULL values, those being:

  - labeling
  - bound styling (e.g. ANGLE [myangleitem])
  - CGI templated output
  - GML output
 
I'm sure I'm missing components but these are the biggies. Seems like we should
capitalize on storage of everything in strings.

Steve

>>> On 10/8/2007 at 10:31 AM, in message <470A4D40.1080004 at pobox.com>, Frank
Warmerdam <warmerdam at POBOX.COM> wrote:
> Umberto Nicoletti wrote:
>> Probably when the column is null it is evaluated by OGR to the empty
>> string and the expression (after replacing [HINDERCATEGORIE] with '')
>> becomes ' = 1' which is invalid.
> 
> Bart / Umberto,
> 
> I can confirm that the mapogr.cpp code implementing the MapServer OGR
> connection type does not check for null-ness of a field.  It just
> calls the OGR GetFieldAsString() function and leaves it to OGR to do
> as it wishes.  OGR will return an empty (but not NULL) string as the
> representation of a NULL field value regardless of type.
> 
>> Just a side note: starting with mapserver 5 the shapefile provider
>> will return 0 for null numeric columns and '' for null strings.
> 
> Like Bart, I'm a bit dubious about this approach though in the absence
> of a more explicit NULL approach I suppose it is no worse than producing
> an error.
> 
> MapServer attributes are always kept internally as strings, and we can't
> practically have any of the item values be NULL without having to very
> carefully touch a lot of code.  So, we *could* potentially add a special
> string representation for null fields, and try to return this consistently
> from all providers.  Then declare some particular rules to use for NULL 
> fields
> in the expression evaluator.
> 
> eg.
> 
> 1) Return '*NULL*' for null field
> 2) Treat '*NULL*' specially in numeric calculations as being not equal to
> any value or in any range.  So the only numeric test that would succeed for
> *NULL* would be != (also expressable as <>).
> 3) Treat '*NULL*' to not match any string expression except *NULL*.
> 
> Hmm, even as I start writing this down, I can see that some additional
> thought is required.  Nevertheless, if there is someone more interested
> in this issue than me, it would be worth following up with an RFC and
> implementation for 5.2.  I'd be happy to fix mapogr.cpp to return NULL
> field values in some particular form.
> 
> Best regards,