Added support for JDBC, added sample jar for Hazelcast

[devops-42]

What type of PR is this?

• [ ] Refactor
• [X] Feature
• [ ] Bug Fix
• [ ] New Query Runner (Data Source)
• [ ] New Alert Destination
• [ ] Other

Description

This PR brings a new Data source JDBC into redash. This allows to connect to sources offering a JDBC interface.

How is this tested?

Testing is coming soon.

• [ ] Unit tests (pytest, jest)
• [ ] E2E Tests (Cypress)
• [ ] Manually
• [ ] N/A

Related Tickets & Documents

Mobile & Desktop Screenshots/Recordings (if there are UI changes)

[codecov[bot]]

Codecov Report

Attention: Patch coverage is 48.48485% with 17 lines in your changes are missing coverage. Please review.

Project coverage is 63.78%. Comparing base (15e6583) to head (a6104a5). Report is 1 commits behind head on master.

:exclamation: Current head a6104a5 differs from pull request most recent head 0f5e04d. Consider uploading reports for the commit 0f5e04d to get more accurate results

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #6854      +/-   ##
==========================================
- Coverage   63.82%   63.78%   -0.04%     
==========================================
  Files         161      162       +1     
  Lines       13060    13093      +33     
  Branches     1803     1806       +3     
==========================================
+ Hits         8335     8351      +16     
- Misses       4425     4442      +17     
  Partials      300      300              

Files	Coverage Δ
redash/serializers/__init__.py	78.51% <ø> (ø)
redash/settings/__init__.py	98.64% <ø> (ø)
redash/query_runner/jdbc.py	48.48% <48.48%> (ø)

[justinclift]

@devops-42 Good to see enthusiasm. :smile:

While you're at it, please fill out the fields in the top comment so the other developers have some idea what this is for. :grin:

---

Would you be ok to add further tests to this, to increase the code coverage and get the codecov checks to pass?

[justinclift]

Interestingly, it looks like Hazelcast have moved to be Open Core:

https://hazelcast.com/blog/changes-to-community-edition/

The "not making CVE fixes available to the Community until the next point release" sounds super dangerous. :frowning:

At first read, the other items sound reasonable (to me) though.

[justinclift]

On a different note, it looks like there are official Hazelcast docker images:

https://hub.docker.com/r/hazelcast/hazelcast/

We could potentially use those for automatically testing this new data source, to make sure it doesn't bit rot over time to the point of breakage.

---

Looks like there's an official Hazelcast Python (client) library too:

https://pypi.org/project/hazelcast-python-client/

@devops-42 Would it have been better to use that, rather than go the JDBC route?

Am guessing you've seen that already though, and figured JDBC was the better approach here. :smile:

[devops-42]

On a different note, it looks like there are official Hazelcast docker images:

https://hub.docker.com/r/hazelcast/hazelcast/

We could potentially use those for automatically testing this new data source, to make sure it doesn't bit rot over time to the point of breakage.

Looks like there's an official Hazelcast Python (client) library too:

https://pypi.org/project/hazelcast-python-client/

@devops-42 Would it have been better to use that, rather than go the JDBC route?

Am guessing you've seen that already though, and figured JDBC was the better approach here. 😄

Hey @justinclift,

have seen it. I considered to go the JDBC way to have a data source, which might be used for other JDBC connections too. :)

[devops-42]

Interestingly, it looks like Hazelcast have moved to be Open Core:

https://hazelcast.com/blog/changes-to-community-edition/

The "not making CVE fixes available to the Community until the next point release" sounds super dangerous. 😦

At first read, the other items sound reasonable (to me) though.

The future handling of CVE is indeed an issue 😐 Maybe the community is strong enough to mitigate this.

[justinclift]

I considered to go the JDBC way to have a data source, which might be used for other JDBC connections too. :)

No worries, as long as it works reliably. :smile:

[arikfr]

I appreciate the enthusiasm here and the effort put already, but I don't think we should merge this. The usefulness of a JDBC connector is very limited -- I doubt there are meaningful databases that have only JDBC connector and don't have alternative options. But on the other hand it will bloat our Docker image and add extra dependencies to maintain over time, that I doubt many on the current team use or familiar with.

An alternative path for you (or whoever interested in JDBC) is to build a custom image on top of the official one that adds the JDBC dependencies and the JDBC query runner. The way Redash is built it should be possible to do so without having to build your own image from scratch.

[justinclift]

It's been a few months since the Hazelcast people announced they're not including security fixes (not even urgent ones) in their Community release. Looking at their Feature Comparison page, it seems like they're not changing that stance to anything reasonable:

https://hazelcast.com/products/feature-comparison/

Personally, I don't reckon we should support an organisation that deliberately puts their users at risk. As in, lets not merge any form of this, whether it be JDBC based, Python based, etc. :smile:

Or am I being unreasonable? :smile: