[gdal-dev] HANA driver proposal

[Rylov, Maxim]

Hi Even,

Thank you for your prompt reply.

> “I assume the driver would depend on the ODBC library, and would require users to build 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 https://github.com/OSGeo/gdal/tree/master/gdal/third_party like we did in QGIS (see https://github.com/qgis/QGIS/tree/master/external/odbccpp).

Note, that any HANA plugin (GDAL/QGIS) also requires the SAP HANA Client (https://tools.hana.ondemand.com/#hanatools) to be able to connect an SAP HANA database.

> “Below a non-exhaustive lists of points that should be covered IMHO. A number of them are open questions where input from the community is welcome.
- criteria for acceptance:
    * (obvious) source code contributed to the repository should follow its licensing terms”

The license will be X/MIT.

>   “* is the driver of sufficient general interest ? For example, we'd likely don't want to accept drivers for a in-house file format of a company/organization that isn't distributed outside it.”

This is not the case for the HANA driver.
>  “* should we require CI tests ? Some tests, especially ones relying on external services, can be flaky.”

We can consider adding CI tests either using a HANA instance in the cloud or in a docker container.

> “- each (at least, new) driver should have at least one name in front of it in the list in https://github.com/OSGeo/gdal/wiki/Maintainers-per-sub-system . What should we expect from the maintainer: monitoring of the mailing list and issue tracker (at least bi weekly ?), some form of handling of it (making sure the issue is well described, and some time frame to address it when relevant), reviewing pull requests in their "area of responsibility" (... and outside it. For example, I see a number of QGIS developers having reviewed your pull requests, but did you help reviewing their pull requests. I don't mean to pinpoint on anybody in particular, as it is a general pattern in most GDAL driver contributions too), participation to general / cross-driver maintenance tasks, ...”
There will be a contact person at SAP responsible for the maintenance.

> “- if someone refactors GDAL internals, who is responsible for adjusting the various drivers to build and work properly ? Open question honestly, and from my experience, this ………………….”

​Unfortunately, we are not able to answer the remaining raised points as they are beyond our expertise.
Perhaps they should be addressed in a separate dedicated discussion.

Kind regards,
Maxim Rylov on behalf of the HANA Spatial Team
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20210726/de7e3385/attachment.html>