Add support for Ocient db to openjump

[jasonar81]

Ocient contributes this code as licensed under GPLv2.

Requires the Ocient JDBC driver v2.00 or higher, which is available here under the Apache 2.0 license. https://mvnrepository.com/artifact/com.ocient/ocient-jdbc4

[jasonar81]

This is the PR for adding support for Ocient db to openjump that was discussed on the mailing list. (Jason Arnold - jarnold@ocient.com).

[edeso]

hey Jason,

your pull request is in our pipeline and awaiting the go from our project members. please be patient. ..ede

ps. at a first glance it's looking good. maybe lacking some documentation but we'll get back to you on that.

[mukoki]

hey jason, Is there an easy way to test openjump ocient driver with a small ocient database ? I saw the link to the jdbc-driver but don't know if we can easily use a local or online base for tests. I had a very quick look at the code and have a little warning about the usage of database numeric type. Currently, attribute types supported by openjump are the ones returned by AttributeType.basicTypes(). I think that other types defined in AttributeType like numeric are converted to one of the basic types like double here and there, but it is not totally safe to use it.

[jasonar81]

I wrote this line in the Ocient DSMetadata code OcientDSMetadata.java:117: else if (type == AttributeType.NUMERIC) return "decimal";

because of this line in another file

SpatialDatabasesDSMetadata.java:690: else if (type == AttributeType.NUMERIC) return "numeric";

for us, it has to be called decimal (not numeric), so I assumed this was the right thing to do. Is that an incorrect assumption?

[jasonar81]

Let me see if I can get an Ocient system up on a public IP that you can hit that has GIS data loaded. I can probably get it done, but it will likely be a little while.

This summer we hope to have a docker container version of the database that can be used for testing. But that's not ready yet.

The challenge here is that Ocient requires NVMe drives and the smallest allowed configuration involves at least 5 servers and I don't think the database will even start if the server has less than 128GB of RAM.

Our customer deployments are typically 15 - 25 dual socket nodes and 1.5TB of RAM per node, and 100gbps networking, and 8 NVMe drivers per node, etc.

The docker container version should be able to run on a single machine, won't require any specific HW, other than that it will still probably require at least 64GB of RAM.

[mukoki]

I wrote this line in the Ocient DSMetadata code OcientDSMetadata.java:117: else if (type == AttributeType.NUMERIC) return "decimal";

because of this line in another file

SpatialDatabasesDSMetadata.java:690: else if (type == AttributeType.NUMERIC) return "numeric";

for us, it has to be called decimal (not numeric), so I assumed this was the right thing to do. Is that an incorrect assumption?

You're right : I did not read correctly. As it is from OpenJUMP type to Ocient database type, it is perfectly safe.

[mukoki]

Let me see if I can get an Ocient system up on a public IP that you can hit that has GIS data loaded. I can probably get it done, but it will likely be a little while.

This summer we hope to have a docker container version of the database that can be used for testing. But that's not ready yet.

The challenge here is that Ocient requires NVMe drives and the smallest allowed configuration involves at least 5 servers and I don't think the database will even start if the server has less than 128GB of RAM.

Our customer deployments are typically 15 - 25 dual socket nodes and 1.5TB of RAM per node, and 100gbps networking, and 8 NVMe drivers per node, etc.

The docker container version should be able to run on a single machine, won't require any specific HW, other than that it will still probably require at least 64GB of RAM.

Wow, this is far beyond what I can do with my little laptop. No problem.

[jasonar81]

We already have a small virtual system on a public IP for Tableau to test against apparently. Sounds like I can get this added to that and get you access. Going to take a while still, but hopefully by the end of the month.

[mukoki]

Jason,

After a discussion with other developpers, we think that the plugin you wrote should be placed in an (optional) extension rather than in the core code of OpenJUMP.

There is an example of such an extension with the drillgis plugin.

The only missing part for a better user experience was the possibility to include the driver specific icon in the extension. This should now be possible after this commit. Now, you should be able to include the driver Icon into your code and package the driver as an extension.

Let us now as we could at least reference ocient extension in the project documentation.

[jasonar81]

We will look at how to make it an extension and will evaluate whether that makes sense to be contained within our driver jar or a different jar. Temporarily targeted to have this completed on our end by end of june.

[jasonar81]

We changed this to be a plugin and packaged it in our JDBC jar and its all working fine.

[edeso]

hi Jason,

we are preparing the first release of OJ2 with some API breaking changes compared to OJ1.x . if case you are still interested to keep your extension alive you might need to readapt it.

as the extension lives now in your JDBC driver i will close this pull request.

regards ..ede