[GRASS-dev] [GRASS GIS] #2851: v.in.ogr: imports empty values as empty strings instead of NULL values

[GRASS GIS]

#2851: v.in.ogr: imports empty values as empty strings instead of NULL values
--------------------------+----------------------------------
  Reporter:  mlennert     |      Owner:  grass-dev@…
      Type:  defect       |     Status:  new
  Priority:  normal       |  Milestone:  7.0.3
 Component:  Default      |    Version:  svn-trunk
Resolution:               |   Keywords:  vector v.in.ogr null
       CPU:  Unspecified  |   Platform:  Unspecified
--------------------------+----------------------------------

Comment (by mlennert):

 Replying to [comment:2 marisn]:
 > Although I am more purist and would say that NULL should be NULL, here's
 opinion why "no data" should be text (from Django framework):
 >
 > "Avoid using null on string-based fields such as CharField and TextField
 because empty string values will always be stored as empty strings, not as
 NULL. If a string-based field has null=True, that means it has two
 possible values for “no data”: NULL, and the empty string. In most cases,
 it’s redundant to have two possible values for “no data;” the Django
 convention is to use the empty string, not NULL."
 > https://docs.djangoproject.com/en/1.9/ref/models/fields/#null
 >
 > If it comes down to voting, my vote goes for keeping NULL as NULL (do
 not alter data unless asked for).

 I agree with you. NULL is a concept that is different from the empty
 string, even though in some cases they are equivalent (e.g. AFAIK there is
 no way to distinguish between the two in a csv file...).

 In the case of this specific bug the issue is specifically for date fields
 which, IIUC, are only supported as such in OGR since 1.3 (but even Debian
 Squeeze, aka oldoldstable is beyond that version, so that should not be an
 issue). So a compromise solution could be to nullify the date and time
 fields (i.e. the first change in the patch), but not the string fields.

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/2851#comment:3>
GRASS GIS <https://grass.osgeo.org>