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 <warmer...@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, > warmer...@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@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev > -- ________________________________________________________ Anders Moe Managing Director Geocap w: +47 22 95 56 63 anders....@geocap.no ________________________________________________________
_______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev