[gdal-dev] Oracle support available by default in any OSGeo software

[Ivan Lucena]

Hi Vincent,

So I think we can agree that OCILIB does not bring any advantage other than some unlikely inconvenience of having OCI header and libraries available. You cannot remove the dependence of having access to an Oracle server anyway.

The use of OCILIB was evaluated and discussed during the development of GDAL/GeoRaster and it didn't make the final cut. I know that some other FOSS projects went to the same conclusion.

But you are absolutely right, the OGR/OCI driver does need some love and care. I would suggest reusing the code in frmts/georaster/oci_wrapper.h to access OCI. That same code is already shared by others OSGeo projects to support Point Cloud data for example. 

But again, changing the OCI wrapper or using a "dependency-free" wrapper is not going to give you any improvement. After that someone would need to look into performance issues and limitations, anyway.

Today, the GDAL/GeoRaster driver have a limitation. It does not support RPC. It is just a matter of passing some metadata notation to and from the driver to GDAL but when the driver was first develop GDAL didn't support RPC. The OGR/OCI driver must have some of those historical reasons too.

Thanks for your interest in helping.

Best regards,

Ivan


>  -------Original Message-------
>  From: vincent rogier <vince.rogier at gmail.com>
>  To: Ivan Lucena <ivan.lucena at princeton-ma.us>
>  Cc: Nicolas Simon <nicolas.simon at spw.wallonie.be>, gdal-dev at lists.osgeo.org
>  Subject: Re: [gdal-dev] Oracle support available by default in any OSGeo software
>  Sent: Jul 23 '12 13:02
>  
>  Hi all,
>  
>  I just want to add some precisions about what was said in that
>  conversation.
>  
>  Ivan is right, OCILIB is a wrapper around OCI.
>  But OCILIB can be built without any dependencies as it does not require
>  oracle headers or libraries to compile and it can dynamically load any
>  Oracle Client runtime.
>  
>  If the current used driver is stable, fully compliant with its desired
>  usage and if it delivers acceptable performances, there is no point trying
>  to make another one using OCILIB for example.
>  
>  I had a quick look at the gdal oci driver wiki page. It apparently shows
>  some limitations.
>  I also looked at the code, and it seems limited in some areas such as
>  data type support, ...
>  It could be also optimized in terms of OCI usage and performances.
>  
>  I often see discussion in dev mailing lists like this one. And sometimes, i
>  see negative reactions about using a third party wrapper for OCI because
>  there are just wrappers. Yes, indeed, But wrappers like OCILIB handle all
>  the common nightmares like portability across platforms, runtime oracle
>  versions, and delivivers a much more maintainable application code, much
>  shorter code, performance improvement due to OCI internal expertise,
>  etc....
>  
>  But once again, if the current driver matches its intended use really well,
>  is stable, scalable and does not restrict future enhancements, you should
>  stick to it and grab some pre built binaries for you OS.
>  
>  
>  Best regards,
>  
>  Vincent
>  
>  
>  On Mon, Jul 23, 2012 at 7:26 PM, Ivan Lucena <[LINK:
>  mailto:ivan.lucena at princeton-ma.us] ivan.lucena at princeton-ma.us> wrote:
>  Nicolas,
>  
>  If you install QGIS from OSGeo4W you should be able to also install the
>  Libs package "gdal-oracle: OGR OCI and GDAL GeoRaster Plugins for Oracle"
>  with the files gdal_GEOR.dll and ogr_OCI.dll. That is all you need in QGIS.
>  
>  But if you don't use OSGeo4W you can grab the same files from Tamas
>  Szekeres website (see [LINK:
>  http://trac.osgeo.org/gdal/wiki/DownloadingGdalBinaries]
>  http://trac.osgeo.org/gdal/wiki/DownloadingGdalBinaries).
>  
>  
>  >  >  I't very frustrating, each time I would like to use OSGeo
>  software
>  >  >  (GDAL/OGR, QGIS, ...) they don't support oracle database.
>  Every time,
>  
>  >  >  everything should be recompiled from source with oracle support
>  enabled. A
>  >  >  long and not easy process...
>  
>  I understand your frustration. But note that all GDAL/OGR driver that have
>  dependency should not be incorporated by default into product distribution
>  to avoid annoying "cannot find shared library xxx" messages or any other
>  more serious error. Those driver are build as plugins so that they can be
>  easily added or removed from the path.
>  
>  
>  >  >
>  >  >  The reason usually evoked for this situation, is that Oracle build
>  >  >  needs Oracle files that aren't freely redistributable. Ok
>  It's a good
>  >  >  reason.
>  
>  You can freely download all the necessary files to compile against OCI
>  from [LINK: http://oracle.com] oracle.com.
>  
>  >  >
>  >  >  I found a library, called OCILIB (<[LINK:
>  >  >  [LINK: http://orclib.sourceforge.net/]
>  http://orclib.sourceforge.net/] [LINK: http://orclib.sourceforge.net/]
>  http://orclib.sourceforge.net/>), that
>  
>  >  >  enable your software to dynamically connect to your oracle
>  database. This
>  >  >  library does not require any oracle library to compile. It's
>  available on
>  >  >  any platform where oracle client is available and it licensed with
>  LGPL.
>  
>  The OCILIB library is just a shell around OCI. You still need OCI
>  distribution from a server, client or instant client installation in order
>  to compile or run any code based on that library.
>  
>  
>  >  >  But before going further, I would like to know if it seems to you
>  a
>  >  >  good way to have Oracle support available by default in any OSGeo
>  software
>  
>  The OSGeo4W and Tamasz packages solutions are working pretty well for
>  Windows users, so far. For QGIS all you have to do is to enable the Oracle
>  Raster driver, is you want to use GeoRaster. Works pretty fast if the image
>  has overviews. Please note that other OSGeo and commercial software can
>  also access Oracle Spatial through GDAL.
>  
>  
>  >  >  Depending of your answers, I 'll come back to ask you how
>  it's the
>  >  >  best way to do that ?
>  
>  I hope that would answer your question.
>  
>  Regards,
>  
>  Ivan
>  
>  
>  --
>  Vincent Rogier