[gdal-dev] Coding for appending to a database in OGR

[Even Rouault]

Selon Peter J Halls <P.Halls at york.ac.uk>:

Not using it, it's hard for me to comment on OCI peculiarities. I've looked
quickly at the code of ogroctitablelayer.cpp and it seems to be consistant with
the behaviour you describe : if you set a FID before using CreateFeature() it
will use it, otherwise it will use a serial number incremented on OGR side, that
is initially set at 1 at datasource opening. I have no clue if it is
wanted/expected for some reason... That seems to be related with the way the FID
column is discovered. I see this :

/* -------------------------------------------------------------------- */
/*      What is the name of the column to use as FID?  This defaults    */
/*      to OGR_FID but we allow it to be overridden by a config         */
/*      variable.  Ideally we would identify a column that is a         */
/*      primary key and use that, but I'm not yet sure how to           */
/*      accomplish that.                                                */
/* -------------------------------------------------------------------- */
    const char *pszExpectedFIDName =
        CPLGetConfigOption( "OCI_FID", "OGR_FID" );

So there's no real guarantee on the characteristics of the FID column. It could
even have no uniqueness constraint.

Generally/ideally, the driver should be able to set automatically the FID of the
feature that is passed to CreateFeature() with a unique value, especially when
the FID is a RDBMS auto-increment column. This is for example done in the 
SQLite driver. The patch I mentionned in my previous post about the PG driver
also aims at doing that. The Shape driver also seems to do it that way.

So there's perhaps place for improvements in OCI driver.

> Even and team,
>
>     following the hint from Even's post below, I have been experimenting with
> OGR_F_SetFID to get the FID for appends to increment beyond the existing
> value,
> rather than always to start at 1.  I'm testing against the OCI driver and am
> not
> (yet) using 1.8.
>
>     I've found that there appears to be no way to 'reset' the starting FID
> value
> used by the driver for output.  I can certainly set the FID to an arbitrary
> value for a specific record, but the internal counter does not appear to be
> reset-able.  This means that I must manage the FID values externally to OGR
> when
> appending to an existing dataset in order to avoid new records being added
> with
> OGR_FID values restarting from 1.
>
>     Is this what is expected / intended?
>
>     The observed behaviour does not quite seem to be as one might expect -
> especially for the database drivers where the FID is to become the primary
> key
> and so must have unique values.  At present it would appear that this
> condition
> is broken when OGR is used to append.  Indeed, were I to create a table with
> a
> unique constraint on OGR_FID, appends would fail once there are records in
> the
> table.
>
>     I've also tried reading the last record in the table and reading the
> table
> until there are no more records to read, but neither seem to have any impact
> on
> the initial FID value when writing.
>
>     Is this a peculiarity of the OCI driver?
>
> Thanks and best wishes,
>
> Peter
>
> Even Rouault wrote:
> > Hi Peter,
> >
> > Do you mean that just after issuing a CreateFeature(), the feature ID isn't
> set
> > to the correct value (the one that you'll find after dataset reopening) ?
> >
> > You have to be more specific about which OGR driver you are talking about
> > because the mechanisms for setting/retrieving FID is driver specific.
> >
> > Perhaps a small snippet of code would help to understand what you do /
> would
> > like to do.
> >
> > If you're interested in the PG driver, here's a relevant ticket :
> > http://trac.osgeo.org/gdal/ticket/3744
> >
> > Best regards,
> >
> > Even
> >
> >> Dear Team,
> >>
> >>      I've reviewed the change log for release 8 so far and do not think
> that
> >> this question is version specific.
> >>
> >>      I'm coding to support an incremental process for loading a large
> spatial
> >> database from a set of distribution objects.  I have noted that my present
> >> approach results in the OGR_FID column values restarting at 1 for each
> >> append.
> >> This is clearly an error!  However, there does not appear to be a method
> for
> >> initialising the 'nextfidtowrite' value in the API.  What is the best
> >> strategy
> >> to adopt?
> >>
> >>      So far as I can see, there appear to be two options.  One is to read
> >> every
> >> feature until there are no more to read: I'd rather not do that.  The
> other
> >> would involve opening the layer, reading the featurecount and then
> requesting
> >> the featurecount'th feature - featurecount'th + 1 should give an error.
> Both
> >> methods should leave the current feature being the last existing feature,
> but
> >> is
> >> this sufficient to effectively initialise the value at which the next FID
> >> will
> >> start?
> >>
> >> Thanks and best wishes,
> >>
> >> Peter
> >>
> >>
> >
>
--------------------------------------------------------------------------------
> >> Peter J Halls, GIS Advisor, University of York
> >> Telephone: 01904 323806     Fax: 01904 323740
> >> Snail mail: IT Services, University of York, Heslington, York YO10 5DD
> >> This message has the status of a private and personal communication
> >>
> >
>
--------------------------------------------------------------------------------
> >> _______________________________________________
> >> gdal-dev mailing list
> >> gdal-dev at lists.osgeo.org
> >> http://lists.osgeo.org/mailman/listinfo/gdal-dev
> >>
> >
> >
>
> --
>
--------------------------------------------------------------------------------
> Peter J Halls, GIS Advisor, University of York
> Telephone: 01904 323806     Fax: 01904 323740
> Snail mail: IT Services, University of York, Heslington, York YO10 5DD
> This message has the status of a private and personal communication
>
--------------------------------------------------------------------------------
>