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.luc...@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.si...@spw.wallonie.be>
> > To: gdal-dev@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 : fwarmer...@gmail.com
> [mailto:fwarmer...@gmail.com]De la part de
> > > Frank Warmerdam
> > > Envoyé : lundi 4 juillet 2011 15:10
> > > À : Nicolas Simon
> > > Cc : gdal-dev@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.si...@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,
> > > 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
>
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
