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

[Peter J Halls]

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
--------------------------------------------------------------------------------