[MDEV-13388] CONNECT Engine shows no support for JDBC Created: 2017-07-27 Updated: 2020-12-01 |
|
| Status: | Open |
| Project: | MariaDB Server |
| Component/s: | Storage Engine - Connect |
| Affects Version/s: | 10.1.22, 10.2.4 |
| Fix Version/s: | 10.2 |
| Type: | Bug | Priority: | Major |
| Reporter: | Donald Langhorne | Assignee: | Olivier Bertrand |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | connect-engine | ||
| Environment: |
Both Mac OS X and Debian |
||
| Description |
|
I am trying to get the CONNECT JDBC engine to work with any one of the following environments: Mac Sierra using either MacPorts or HomeBrew, Docker container with Alpine as a base and adding into it OpenJDk8, MariaDB-10.1.22. First, I have been able to get all the way through on an Ubuntu 16.04 system and was able to use the JDBC CONNECT engine along with a 3rd party JDBC driver for Excel and created a table connected to my excel file, which is my ultimate goal. I mention this because in getting that to work, I had to work through a number of hurdles so overall I'm aware of the needed steps to get this to work. I replicated my steps in a VirtualBox VM running Ubuntu 16.04 that oddly had one glaring issue, but I was able to resolve it by not autostarting mariaDB and instead running it from the command line using mysqld_safe. That problem I may report in another issue, it's somewhat related but there was a workaround to get that to work, not so with these other environments. I'll highlight the general steps I've taken on the docker alpine system and where I'm stopped:
This is where I'm stuck, when I stop/start my mariaDB server it won't start and complains that those 2 parameters are unknown (Don't remember the exact language). If I remove them, start my server and then run:
it shows all matching variables that have 'connect' in the name. I do see some of the CONNECT engine variables, such as connect_conv_size and most of the others, but connect_class_path, connect_jvm_path and connect_java_wrapper are not listed. I am afraid at this point I'm stuck. I'd be happy to start seeing 'can't find JdbcInterface.jar' but I am not at that point yet, seems the CONNECT engine is behaving like there is no support at all for JDBC. I ran into this on my mac as well using MacPort and Homebrew and I might add all of these have been different mariadb versions: Alpine: Provides MariaDb-10.1.22, used OpenJDK8 Just to circle back quickly to Ubuntu, once I set those variables which were simply present as soon as I activated the connect engine, then put the JdbcInterface.jar in the right place and my 3rd party JDBC Excel Driver, I was off and running. The problem so far is I really need to be able to get this working locally for me. For now I'm managing with a VirtualBox VM but I would really prefer to run MariaDB directly on my mac. Everything but the JDBC Connect engine works just fine on my Mac. Failing that a docker container would be my next choice, but so far I have not had any luck. Docker may in fact be preferred as I can then deploy this setup more easily to other staff at my company. I don't know if I am missing certain library files or if for some reason I need to configure java environment variables (I never did on the ubuntu systems). but I am really stuck. There are no errors in the startup log file so I don't know what else to try. Any help would be greatly appreciated. One additional note, a few weeks ago when I was trying to get this to work on my Mac, I was able to use the CONNECT engine and CSV files to link a CSV file to a table in my mariadb database so the CONNECT engine does generally work on Mac, but the JDBC table type does not. If I get this all to work with docker I'll be posting it to Docker Hub which will make it easier for others to play around with the CONNECT engine and JDBC. If I'm successfull, I'll circle back to this issue and report the docker hub name of the container for others. |
| Comments |
| Comment by Olivier Bertrand [ 2017-08-01 ] | ||||||||||||
|
Indeed the CMakeLists.txt file for CONNECT contains for JDBC these lines:
I don't know who has written this and why, not being a specialist of CMAKE and the way it works for MariaDB. But it would confirm that JDBC tables are not currently supported for Apple machines. A turnaround could perhaps be to compile MariaDB from source after having edited the CMakeLists.txt file to remove this restriction. It would be also interresting to know why this retriction was added to CONNECT, but I am not the person who can answer that question. | ||||||||||||
| Comment by Sergei Golubchik [ 2017-08-03 ] | ||||||||||||
|
The default (no JDBC support on OSX) should be changed in the next version. Until then you can override it manually, by compiling with
| ||||||||||||
| Comment by Donald Langhorne [ 2017-08-03 ] | ||||||||||||
|
Hi thanks for the response. I'm assuming that wherever else aside from Mac I've run into this, this may be the reason (IE the package for a specific Linux package may be omitting or actively disabling this feature. Once this works on Mac, I'll be a happy camper. FYI I have tried to compile MariaDB myself on Mac Sierra recently and it failed. Unfortunately I didn't make note of the error and have since deleted the source on my Mac. I was trying to compile Version 10.2 FYI. Generally I tried to follow these instructions: https://mariadb.com/kb/en/mariadb/Build_Environment_Setup_for_Mac/ however they are sorely out of date. It would be great if someone could update that. If you want I would be willing to redownload and try compiling again to provide the compile error details. Last thing: I have managed to get this to work in Docker on my Mac. The trick was to grab the Dockerfile and associated files from the official MariaDB repository found here: https://github.com/docker-library/mariadb/tree/198f04b24ca6f668357106355b03d38d1f3234bc/10.2 I then modified the Dockerfile to use ubuntu:latest instead of debian:jessie and built my own Docker image. There are a few other changes needed to get this off the ground but nothing major. I will eventually upload my changes to Dockerhub but I customized a number of things for my specific needs so I'll need to rework it to be more generally usable first. |