-
Notifications
You must be signed in to change notification settings - Fork 1
Java: Modernize page #385
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Java: Modernize page #385
Conversation
WalkthroughReplaced the Java connection docs with a structured page that includes link includes, separate PostgreSQL JDBC and CrateDB JDBC sections (Synopsis, Maven, Gradle, Download), examples and a full CrateDB JDBC runnable example, plus updated testing references. Documentation-only changes; no code/API edits. (≈ thirty words) Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Suggested labels
Pre-merge checks and finishing touches✅ Passed checks (3 passed)
✨ Finishing touches🧪 Generate unit tests (beta)
📜 Recent review detailsConfiguration used: CodeRabbit UI Review profile: CHILL Plan: Pro 📒 Files selected for processing (1)
🧰 Additional context used🧠 Learnings (2)📚 Learning: 2025-10-08T01:34:18.867Z
Applied to files:
📚 Learning: 2025-08-05T07:14:57.416Z
Applied to files:
🪛 markdownlint-cli2 (0.18.1)docs/connect/java.md84-84: Bare URL used (MD034, no-bare-urls) 135-135: Bare URL used (MD034, no-bare-urls) 178-178: Bare URL used (MD034, no-bare-urls) ⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 2
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
docs/connect/java.md
(3 hunks)
🧰 Additional context used
🧠 Learnings (1)
📚 Learning: 2025-08-05T07:14:57.416Z
Learnt from: hammerhead
PR: crate/cratedb-guide#221
File: docs/connect/configure.md:58-66
Timestamp: 2025-08-05T07:14:57.416Z
Learning: In CrateDB connection strings, the user:password@ syntax is valid for HTTP Basic authentication on port 4200, but PostgreSQL JDBC drivers do not support this format and require credentials as query parameters (?user=<user>&password=<password>) instead.
Applied to files:
docs/connect/java.md
🪛 markdownlint-cli2 (0.18.1)
docs/connect/java.md
83-83: Bare URL used
(MD034, no-bare-urls)
167-167: Bare URL used
(MD034, no-bare-urls)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: Build docs
properties.put("password", "<PASSWORD>"); | ||
properties.put("ssl", true); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Store JDBC properties as strings
Properties.getProperty(...)
returns only String values. By writing a Boolean (true
) for ssl
, the driver sees null
, so SSL stays off. Use setProperty("ssl", "true")
(and consider doing the same for the other keys for consistency).
-properties.put("ssl", true);
+properties.setProperty("ssl", "true");
Apply this in both JDBC snippets and the full example.
Also applies to: 102-104, 132-134
🤖 Prompt for AI Agents
In docs/connect/java.md around lines 46-47 (and also apply the same change at
lines 102-104 and 132-134), JDBC Properties are being set with a boolean value
for "ssl" which causes Properties.getProperty(...) to return null; change these
to use string values via Properties.setProperty("ssl", "true") (and similarly
setProperty for other keys like "user" and "password" to keep consistency) in
both small JDBC snippets and the full example so the driver reads the values
correctly.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@matriv: Do you agree with this evaluation, or is it nonsense?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
https://jdbc.postgresql.org/documentation/use
ssl (boolean) Default false
Connect using SSL. The server must have been compiled with SSL support. This property does not need a value associated with it. The mere presence of it specifies an SSL connection. However, for compatibility with future versions, the value “true” is preferred. For more information see [Using SSL](https://jdbc.postgresql.org/documentation/ssl/).
Setting up the certificates and keys for ssl connection can be tricky see [The test documentation](https://github.com/pgjdbc/pgjdbc/blob/master/certdir/README.md) for detailed examples.
but in their example above:
props.setProperty("ssl", "true");
So I guess both work
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks. So, we'll keep this unmodified, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it applicable to refer to other Java-related topics at the bottom of the page?
- Software testing:
- Integrations:
- https://cratedb.com/docs/guide/integrate/databricks/
- https://cratedb.com/docs/guide/integrate/debezium/
- https://cratedb.com/docs/guide/integrate/flink/
- https://cratedb.com/docs/guide/integrate/hop/
- https://cratedb.com/docs/guide/integrate/jmeter/
- https://cratedb.com/docs/guide/integrate/kafka/
- https://cratedb.com/docs/guide/integrate/spark/
- https://cratedb.com/docs/guide/integrate/trino/
This comment was marked as off-topic.
This comment was marked as off-topic.
Sorry, something went wrong.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tend not to, I think maybe only the testing
fits here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've added a note per c2a090d, thanks.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looks good, thx, just one comment.
docs/connect/java.md
Outdated
while CrateDB JDBC uses `jdbc:crate://`. | ||
::: | ||
|
||
Applications using the PostgreSQL JDBC Driver may emit PostgreSQL-specific |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
imho we should rephrase to encourage using the postgres jdbc and only if they encounter problems turn to our crate one.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am still not convinced we should really encourage people to use the vanilla driver, because the CrateDB driver offers so many excellent usability features?
I think the shortcomings of the vanilla driver are quickly present, so all serious Java applications are using the CrateDB driver, if I am not mistaken, like our Flink demo code is also doing it? Could you provide feedback here, @zolbatar and @mackerl?
Of course I might not be up-to-date about the situation, so please correct me if I am wrong. Nevertheless, I've added 9f757e3 at your disposal; please suggest any wording improvements. 🙇
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
AFAIK Postgres driver is the first option, this is the one we use in our java integration tests in crate/crate repo.
This is the one that we use for crate-qa client tests. CrateDB is to be used only when hiccups are encountered with the stock jdbc driver.
So I think we should also interchange the sections and mention first the PostgreSQL jdbc and then ours.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks. I've swapped the sections, know about your rationale, but I am still challenging it strongly. I think we are doing a bad service to CrateDB if we keep it like this, because subtle differences in databases should actively be balanced within the driver layer, to not let application developers stranded. All the competitors are doing it excellently for both JDBC and ODBC, and I would like to see that CrateDB will start doing the same.
For example, if we don't modernize and maintain the CrateDB JDBC Driver, we will never be able to conceive a Hibernate dialect on top of it, and only then any database will start getting interesting for many.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't argue against that, but the situation currently is that stock JDBC is in favor.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's not about this PR, so let's merge it. Still I am interested how this situation came into existence. As long as we keep it that way, including the thinking perspective, I fear not much will change here. Maybe there will be another discussion about this topic at a better spot soon. Please provide relevant guidance when possible.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The decision back in the past is that we don't have the manpower to keep track of psql jdbc changes and incorporate them to our own version of the driver and to rather try to make our CrateDB (server side) compatible with the new changes in postgres jdbc, which also makes sense to make it more and more compatible with PostgreSQL tooling in general.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree with @matriv that the Postgres driver is the first option.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tend not to, I think maybe only the testing
fits here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, thx!
Added one more comment though about the ordering: #385 (comment)
About
An attempt to modernize the page about Java/JDBC.
Preview
References