[gdal-dev] HANA driver proposal
even.rouault at spatialys.com
Tue Sep 14 02:15:47 PDT 2021
> Can you point us to an example of a GDAL plugin that is offered as
> download from a GDAL external website?
> This might be an option, but we would prefer contributing directly to
> GDAL, of course. Maintaining binary plugin versions externally for all
> the relevant versions/platforms/compilers will probably be difficult.
For the platforms/compilers part, you already need to do that to provide
the binaries of the ODBC driver. Adding GDAL versions (GDAL driver ABI
generally changes at feature versions) of course would add an extra
dimension to this.
> Would it be sufficient if the OGR SAP HANA driver is reviewed by
> members of our team? And if that’s not sufficient, what options do we
> have to find someone who is qualified to do the final review?
Ultimately you need to find someone who has merge rights to be
enthusiastic enough to press the merge button. Either because he/she has
reviewed itself the code (because he/she's interested naturally in the
work, or you find compelling ways of making him/her interested in it)
and is happy to see his name in the merge commit, or he/she trusts
someone else who has done the review.
I'm interested if other PSC members have an opinion if this should
rather be proposed as a in-tree driver or out-of-tree one.
> Thanks, and best regards,
> *From:*gdal-dev <gdal-dev-bounces at lists.osgeo.org> *On Behalf Of *Even
> *Sent:* Friday, August 13, 2021 7:31 PM
> *To:* Rylov, Maxim <maxim.rylov at sap.com>; gdal-dev at lists.osgeo.org
> *Subject:* Re: [gdal-dev] HANA driver proposal
> > “I assume the driver would depend on the ODBC library, and would require users to
> build https://github.com/SAP/odbc-cpp-wrapper
> <https://github.com/SAP/odbc-cpp-wrapper>as the corresponding ODBC
> driver ?”
> The odbc-cpp-wrapper library is going to be used only during the
> compilation phase and linked statically, thus end users will get
> only one dynamic/shared library of the HANA driver. Hence, no
> additional actions are required from end users. For those who want
> to compile the GDAL sources with HANA support on their own, the
> sources of the odbc-cpp-wrapper are needed. However, this step can
> be omitted if we store a copy of the library in
> we did in QGIS (see
> I can anticipate potential issues if both GDAL and QGIS have a odbcpp
> vendorized copy, and that for some reason they differ in versions.
> That could cause symbol clashes at runtime. Putting the vendorized
> copy in a dedicated namespace prefix (GDAL::) could avoid that.
> Otherwise, isn't the cpl_odbc.h abstraction good enough ?
> Side note: are you aware of https://github.com/nanodbc/nanodbc
> <https://github.com/nanodbc/nanodbc> that is also a C++ wrapper for
> ODBC ? (Mateusz one of our PSC members was the main developer of it,
> although I believe he has retired from it)
> Note, that any HANA plugin (GDAL/QGIS) also requires the SAP HANA
> Client (https://tools.hana.ondemand.com/#hanatools
> <https://tools.hana.ondemand.com/#hanatools>) to be able to
> connect an SAP HANA database.
> Is that the ODBC driver for SAP HANA ?
> Unfortunately, we are not able to answer the remaining raised
> pointsas they are beyond our expertise.
> Perhaps they should be addressed in a separate dedicated discussion.
> Well, if you contribute to GDAL, then that should be in your area of
> interest and concern :-)
> I think the main practical issue for this to go forward is for you to
> find someone who would want to review your contribution.
> Another option is to propose the OGR SAP HANA driver as a plugin for
> download from your website.
> http://www.spatialys.com <http://www.spatialys.com>
> My software is free, but my time generally not.
My software is free, but my time generally not.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the gdal-dev