[gdal-dev] Nullable fields in OGR

Jason Roberts jason.roberts at duke.edu
Thu Feb 18 13:52:30 EST 2010


Even and Frank, thanks for your replies. I am a little confused because you
each appeared to describe different behaviors.

Frank said:

> There is currently no way to test if a datastore supports the concept
> of NULL fields, but if it does not it should just write a default value
> (0.0, empty string, etc).

Even said:

> For relational databases such as SQLite, 
> Postgres or MySQL, this is also supported, unless if you try to write a
NULL 
> value and the schema of the table constraints the column to be non
NULLable, 
> you'll get an error when inserting/updating the feature.

Which one is correct, or is it decided on a per-driver basis, with no policy
specified by the OGR team? If this is too much trivia for you bother with,
let me know and I will try to determine it by looking at the code.

It would be nice if a future version of OGRFieldDefn allowed the caller to
interrogate whether a field can be set to NULL. If it cannot be done, my
personal preference would be for Even's behavior to occur: that
OGRLayer::CreateFeature or SetFeature fails if a NULL field is not allowed
by the underlying format. If NULLs are silently translated to 0.0, empty
string, etc, this could be very bad for certain applications. It would be
nice to protect the user from this, so he doesn't have to remember which
formats support NULL and which do not. I would be happy to create a ticket
if you thought this was worthwhile.

Even, you mentioned that the shapefile driver supports NULL fields. My
understanding is that shapefiles do not support NULL, at least not according
to ESRI. The only exception are date fields, which sort of support NULL. For
more on that, see
http://webhelp.esri.com/arcgisdesktop/9.3/index.cfm?TopicName=Geoprocessing%
20considerations%20for%20shapefile%20output. Does OGR do something
different?

Thanks,
Jason

-----Original Message-----
From: Even Rouault [mailto:even.rouault at mines-paris.org] 
Sent: Thursday, February 18, 2010 1:09 PM
To: gdal-dev at lists.osgeo.org
Cc: Jason Roberts
Subject: Re: [gdal-dev] Nullable fields in OGR

Le Thursday 18 February 2010 18:37:04 Jason Roberts, vous avez écrit :
> Many relational databases allow fields to be set to NULL. Is this
supported
> in OGR? How does one detect whether a field is nullable or not?

All fields in OGRFeature are nullable. I think most OGR drivers will support

writing features with null fields but this must be checked on a case by case

basis. In theory, all drivers should check if the field is null or not. I
can 
imagine that some specialized format could fail if some given compulsory 
fields are unset. From a quick look, drivers such as Shape, BNA, GML, KML, 
GPX, etc.. support null fields.  For relational databases such as SQLite, 
Postgres or MySQL, this is also supported, unless if you try to write a NULL

value and the schema of the table constraints the column to be non NULLable,

you'll get an error when inserting/updating the feature.

>
>
>
> Looking at the class documentation, I see functions OGRFeature::IsFieldSet
> and OGRFeature::UnsetField. Are these intended for checking whether a
field
> is NULL and setting it to NULL?

Yes

> Or are they used for something else, such 
> as determining which fields have been modified by a caller prior to him
> calling OGRLayer::SetFeature?
>
>
>
> When I looked at OGRFieldDefn, I could not find a method that might be
> intended for checking whether a field was nullable (e.g.
> OGRFieldDefn::IsUnsettable).

It doesn't exist. You can always nullify a field in OGRFeature. But there's 
currently no API to be sure that writing it with OGRLayer::SetFeature() or 
OGRLayer::CreateFeature() will actually work.

>
> A while back, Mateusz asked this:
> > Yes. Also, most applications I've seen using OGR do define their own
> >
> > data models and translate OGRFeature to features of their own types.
> >
> > Perhaps it would be interesting to know why they don't use OGRFeature
> >
> > as a part of their data model, what's missing...
>
> I am currently evaluating whether or not I should use OGRFeature directly
> in a data model, or wrap it. Without nullability, I am probably inclined
to
> wrap it. As I have mentioned previously on gdal-dev, I'm trying to build
> something that wraps OGR and ArcGIS APIs behind a common abstraction, to
> allow development of tools that work with both. ArcGIS supports
nullability
> and it is useful in many situations, so I'd like to cleanly preserve it in
> my abstraction, even if OGR does not presently support it.
>
>
>
> Thanks for any thoughts you have,
>
>
>
> Jason





More information about the gdal-dev mailing list