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

[Anders Moe]

An interesting discussion, but shouldn't the layer table have been cread
with a UNIQUE contraint in the ID column in the first place ?

Anders

On Thu, Oct 28, 2010 at 5:02 PM, Frank Warmerdam <warmerdam at pobox.com>wrote:

> Peter J Halls wrote:
>
>> 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?
>>
>
> Peter,
>
> This is a flaw in the OCI driver.  FIDs are supposed to be unique, and
> if the CreateFeature() method is assigning one, it should ensure it is
> unique.
>
> I have reviewed the trunk code, and this seems to be a problem with it too.
>
> My feeling is that the first time iNextShapeId is used in the lifetime of
> an OGROCITableLayer we ought to do a query on the corresponding column
> to find it's max, and use that +1 as iNextShapeId.  This would generally
> avoid conflicts, and would not be as expensive as querying for each
> create feature.
>
> The downside to this approach is that it assumes no one else is adding
> features to the table during the lifetime of the OGROCITableLayer object.
> This is usually safe, but not always.  This is one example of how the
> OGR RDBMS drivers are often not *really* prepared to live cleanly in
> a multi-user / multi-application environment.  It could be "done right"
> but the cost for bulk loads might be quite painful.  Fast bulk loads
> was the original reason for existence of the OCI driver.
>
> If you would like to prepare code for that it would be great.  If not,
> please create a ticket for the issue and hopefully I'll have a chance to
> do it.
>
> Best regards,
> --
>
> ---------------------------------------+--------------------------------------
> I set the clouds in motion - turn up   | Frank Warmerdam,
> warmerdam at pobox.com
> light and sound - activate the windows | http://pobox.com/~warmerdam
> and watch the world go round - Rush    | Geospatial Programmer for Rent
>
>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>



-- 

________________________________________________________

Anders Moe

Managing Director
Geocap
w: +47 22 95 56 63
anders.moe at geocap.no
________________________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20101028/3b5f50b7/attachment.html