Thanks for your reply, Even. Maxim is on vacation, so let me try to answer on his behalf.
Good point about the symbol clashes. We weren’t thinking of that yet. Adding an additional namespace prefix seems to be a good idea. We should introduce that option upstream. Before we implemented our own ODBC wrapper, we checked out existing ones. Indeed, nanodbc seems to be the best maintained wrapper with the most features. However, it does not support batch inserts with data-at-execution parameters (https://docs.microsoft.com/en-us/sql/odbc/reference/develop-app/using-arrays-of-parameters?view=sql-server-ver15), which we consider rather important in a spatial context as the length of geometry values can vary greatly. We considered contributing, but batch inserts with data-at-execution parameters are poorly supported by ODBC drivers. Of the drivers we tested, we found that only PostgreSQL and SAP HANA support it the way we understand the specification. Hence, we preferred to write our own wrapper as the data-at-execution parameters support might be considered a buggy feature. Yes, the SAP HANA Client (https://tools.hana.ondemand.com/#hanatools) contains the ODBC driver for SAP HANA (it also contains database connectors for other languages). The driver is not required at compile time, it’s only required at runtime if you want to connect to an SAP HANA database. 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. 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? Thanks, and best regards, Stefan From: gdal-dev <[email protected]> On Behalf Of Even Rouault Sent: Friday, August 13, 2021 7:31 PM To: Rylov, Maxim <[email protected]>; [email protected] Subject: Re: [gdal-dev] HANA driver proposal Maxim, > “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). 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 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) 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 points as 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. Even -- http://www.spatialys.com My software is free, but my time generally not.
_______________________________________________ gdal-dev mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/gdal-dev
