RE: [gdal-dev] OGR : OCI driver improvement

[Ivan Lucena]

Nicolas,

Don't worry about the raster driver. I am taking care of it but I am glad to know about your interest in maintain the so called OCI driver. That is my suggestion, start from fresh a new driver by another name like SDO, Oracle, SDO_GEOM, or something that represent the data source, not the API name. You can then use the oci_wrapper code in the raster driver so that we can integrate what is good in both implementations. The oci_wrapper is also used by libLAS to access SDO_PC, point cloud that. That means, more people contributing with more better performance code in the benefit of all. Anyway, In the long run, we could then replace the OCI driver by the new one and continue to answer by the name of OCI for backward compatibility. But please note that the oci_wrapper by itself is not going to provide the improvements your want by itself, you still need to write the code anyway. But if the change is so big and the current code is so fragile that could make sense. Just a suggestion.

Regards,

Ivan


>  -------Original Message-------
>  From: Nicolas Simon <nicolas.simon at spw.wallonie.be>
>  To: gdal-dev at lists.osgeo.org
>  Subject: RE: [gdal-dev] OGR : OCI driver improvement
>  Sent: Jul 04 '11 10:22
>  
>  Hi,
>  I just answer most questions in my previous mail to the list.
>  So just to say that I could participate to the maintenance of the OCI driver for OGR (we don't use raster in Oracle, sorry).
>  
>  Nicolas
>  
>  > -----Message d'origine-----
>  > De : fwarmerdam at gmail.com [mailto:fwarmerdam at gmail.com]De la part de
>  > Frank Warmerdam
>  > Envoyé : lundi 4 juillet 2011 15:10
>  > À : Nicolas Simon
>  > Cc : gdal-dev at lists.osgeo.org
>  > Objet : Re: [gdal-dev] OGR : OCI driver improvement
>  >
>  >
>  > Nicolas,
>  >
>  > The proposed changes seem reasonable, but I am concerned
>  > about complexity and
>  > risk of breaking the driver in some rarely tested cases.  The OCI
>  > driver is pretty
>  > fragile.
>  >
>  > On Mon, Jul 4, 2011 at 8:32 AM, Nicolas Simon
>  > <nicolas.simon at spw.wallonie.be> wrote:
>  > > Hi all,
>  > >
>  > > I'd like to propose some OCI driver improvement.
>  > >
>  > > 1) Enable insert from different client. This could be done
>  > by managing the generation of new FID on DB side instead of
>  > client side.
>  > > Technically this could be done with an oracle sequence and
>  > a trigger to fill the FID.
>  > > This proposition modify the way FID are handled ( I propose
>  > to do as in PostGIS driver). This means that the FID of a
>  > feature (i.e. usually the value of the OGC_FID column for the
>  > feature) inserted into a table with CreateFeature() will be
>  > retrieved from the database and can be obtained with GetFID()
>  > even if an non-null FID was provided.
>  > > This could be easily implemented in UnboundCreateFeature
>  > with a 'returning' clause.
>  > > But I don't known if it's feasible in BoundCreateFeature
>  > since truth FIDs will be know later when
>  > OGROCITableLayer::FlushPendingFeatures() is called.
>  >
>  > I'm not clear on what you will do if CreateFeature() is called on a
>  > table for which the
>  > the sequence and trigger to fill the FID do not already exist.  Will
>  > you create it?  I'm
>  > concerned this will not be honoured by other applications
>  > interacting with the
>  > table.
>  >
>  > > 2) By providing true update operation instead of delete +
>  > insert operations (cf SetFeture).
>  > > This should provide better performance and enable to
>  > develop trigger on update if needed for other purpose.
>  > > With this modification, OCI driver will have the following
>  > mapping between OGR concepts and Oracle operations:
>  > >    OGRFeature::CreateFeature() <==> INSERT operation
>  > >    OGRFeature::SetFeature() <==> UPDATE operation
>  > >    OGRFeature::DeleteFeature() <==> DELETE operation
>  > > This modify slightly the actual behavior since it disable
>  > the possibility of inserting a new record through SetFeature
>  > (in case of  they were no record to delete, the subsequent
>  > insert did the job). With the proposed implementation it'll
>  > be no longer the case.  "Update ... set ...  where FID =
>  > provided FID" command doesn't insert new record.
>  >
>  > The main downside I see with implementing SetFeature() as an UPDATE is
>  > complexity -
>  > another whole set of code for assigning records.  But that isn't a
>  > compelling reason
>  > not to do it.
>  >
>  > > 3) Add transaction support in the normal SQL sense.
>  > > Since transaction is handled within a session and we have a
>  > session per OGROCIDataSource, a transaction will include
>  > operation on any layer of that datasource.
>  > > I propose the following operating mode.
>  > >
>  > > Outside a transaction, we'll be in 'auto commit' mode.
>  > >  This commit on success DeleteFeature, SetFeature and
>  > CreateFeature (not in MULTI_LOAD mode).
>  > >  For CreateFeature (in MULTI_LOAD mode) data will be commited
>  > >  - each time the buffer is full (when
>  > OGROCITableLayer::FlushPendingFeatures() is called)
>  > >  - when OGROCITableLayer::SyncToDisk() is call
>  > >  - before a new transaction start.
>  > >
>  > > Transaction start (through a call
>  > OGRLayer::StartTransaction()) for all layer in the DataSource.
>  > > OGRLayer::CommitTransaction() will call
>  > OGROCITableLayer::SyncToDisk() for each layer of  the
>  > DataSource and issues one commit command for the session, and
>  > then return in auto commit mode (cf outside transaction mechanism)
>  > > OGRLayer::RollbackTransaction() will drop PendingFeature
>  > (may be  through a private function that reset
>  > nWriteCacheUsed to 0) for each layer of the datasource and
>  > issues one rollback command for the session, and then return
>  > to auto commit mode.
>  >
>  > This *seems* reasonable, but please understand that the OGR
>  > transaction
>  > model is fairly weak.
>  >
>  > > I would like to know if someone else is interested in these
>  > improvements ?
>  > > Is it the way you want things work ?
>  > >
>  > > An other information is that I'm ready to work for these
>  > improvements.
>  >
>  > I think the changes are desirable (in trunk only!) but if you
>  > provide them
>  > I am hopefully you will take an ongoing interest in maintenance of the
>  > OCI driver.   Hopefully you might also be open to taking on commit
>  > access so you can do stuff more easily (perhaps after first submitting
>  > patches via trac for review).
>  >
>  > 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
>