[Gdal-dev] new RFC 13: Improved Feature Insertion/Update/Delete Performance in Batch Mode

[Baumann, Konstantin]

> -----Original Message-----
> From: Tamas Szekeres [mailto:szekerest at gmail.com]
> Sent: Wednesday, May 16, 2007 4:38 PM
> To: Baumann, Konstantin
> Cc: gdal-dev at lists.maptools.org
> Subject: Re: [Gdal-dev] new RFC 13: Improved Feature
> Insertion/Update/Delete Performance in Batch Mode
> 
> Hi,
> 
> I agree in the purpose of the RFC. However it seems that this
> implementation brings in some new elements in the C++ interface and
> further requirements of the various drivers to implement these
> functions. Hopefully not the mysql is the only driver that would
> implement this functionality.

I think the new interface is easy enough, to allow other OGR drivers to
implement an optimized code path as well...

> Many people use the various SWIG-ged language APIs instead of the
> C/C++ interface. So we should also consider to support these API-s
> with any new additions as well. In this regard implementing typemaps
> for object arrays in not too straightforward and we should eventually
> reconstuct the array iterating through the elements one by one. It
> would certainly bring in additional delays with the completion of the
> overall implementation.
> To support the SWIG interfaces you should also represent these
> function at the GDAL/OGR C API.

The straight forward C API would look like this:

OGRErr OGR_L_CreateFeatures( OGRFeature** papoFeatures, int
iFeatureCount );

I am not familiar with SWIG-wrapping, but would it be more easy to use
an interface like this:

struct OGRFeatureArray {
    OGRFeature** papoFeatures;
    int iFeatureCount;
};
OGRErr OGR_L_CreateFeatures( OGRFeatureArray features );

> I would propose you to examine the option of providing this
> functionality by using the existing API with caching the various
> feature creations / additions / deletions at the provider. These
> changes could be propagated to the datastore in batch using the
> existing transaction mechanism. I'm sure that this behaviour have
> already been implemented in various providers.

Only the SQLite and the PostGIS drivers implement the "transaction"
interface methods of OGRLayer (or is it OGRDataSource?).

Explicitly storing and keeping track of creations, additions, updates,
and deletions and applying these changes later on in time would be
(very) complex and error prone w.r.t. the implementation issues (for
example, to mimic the side effects (e.g. FID updates) of certain
operations ect.)...

I would like to use a simple interface for doing simple operations; the
more complex interfaces (like transactions) should be used for more
complex opertaions, IMHO... :-)

Best regards,
    Kosta