An interesting discussion, but shouldn't the layer table have been cread with a UNIQUE contraint in the ID column in the first place ? <div><br></div><div>Anders<br><br><div class="gmail_quote">On Thu, Oct 28, 2010 at 5:02 PM, Frank Warmerdam <span dir="ltr"><<a href="mailto:warmerdam@pobox.com">warmerdam@pobox.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">Peter J Halls wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Even and team,<br>
<br>
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.<br>
<br>
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.<br>
<br>
Is this what is expected / intended?<br>
</blockquote>
<br></div>
Peter,<br>
<br>
This is a flaw in the OCI driver. FIDs are supposed to be unique, and<br>
if the CreateFeature() method is assigning one, it should ensure it is<br>
unique.<br>
<br>
I have reviewed the trunk code, and this seems to be a problem with it too.<br>
<br>
My feeling is that the first time iNextShapeId is used in the lifetime of<br>
an OGROCITableLayer we ought to do a query on the corresponding column<br>
to find it's max, and use that +1 as iNextShapeId. This would generally<br>
avoid conflicts, and would not be as expensive as querying for each<br>
create feature.<br>
<br>
The downside to this approach is that it assumes no one else is adding<br>
features to the table during the lifetime of the OGROCITableLayer object.<br>
This is usually safe, but not always. This is one example of how the<br>
OGR RDBMS drivers are often not *really* prepared to live cleanly in<br>
a multi-user / multi-application environment. It could be "done right"<br>
but the cost for bulk loads might be quite painful. Fast bulk loads<br>
was the original reason for existence of the OCI driver.<br>
<br>
If you would like to prepare code for that it would be great. If not,<br>
please create a ticket for the issue and hopefully I'll have a chance to<br>
do it.<br>
<br>
Best regards,<br><font color="#888888">
-- <br>
---------------------------------------+--------------------------------------<br>
I set the clouds in motion - turn up | Frank Warmerdam, <a href="mailto:warmerdam@pobox.com" target="_blank">warmerdam@pobox.com</a><br>
light and sound - activate the windows | <a href="http://pobox.com/~warmerdam" target="_blank">http://pobox.com/~warmerdam</a><br>
and watch the world go round - Rush | Geospatial Programmer for Rent</font><div><div></div><div class="h5"><br>
<br>
_______________________________________________<br>
gdal-dev mailing list<br>
<a href="mailto:gdal-dev@lists.osgeo.org" target="_blank">gdal-dev@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/gdal-dev" target="_blank">http://lists.osgeo.org/mailman/listinfo/gdal-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><br>________________________________________________________<br><br>Anders Moe<br><br>Managing Director<br>Geocap<br>w: +47 22 95 56 63<br><a href="mailto:anders.moe@geocap.no" target="_blank">anders.moe@geocap.no</a><br>
________________________________________________________<br><br><br><br> <br><br>
</div>