[gdal-dev] Nullable fields in OGR

[Even Rouault]

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