[gdal-dev] OGR : OCI driver improvement

Tue Jul 5 11:11:18 EDT 2011

Ivan,
	Your suggestion represents a lot of work, but it's interesting. 
	I think, I'll use the existing code unless I feel blocked with it.
	
	Regards

	Nicolas
    

> -----Message d'origine-----
> De : Ivan Lucena [mailto:ivan.lucena at pmldnet.com]
> Envoyé : lundi 4 juillet 2011 23:52
> À : Nicolas Simon; ""
> Objet : RE: [gdal-dev] OGR : OCI driver improvement
> 
> 
> 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 suggestio
>  n.
> 
> 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
>