-
Notifications
You must be signed in to change notification settings - Fork 293
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
Update JDBC docs for V2 #3071
Update JDBC docs for V2 #3071
Conversation
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 discussable. Personally, I don't think we need to create another separate entry in the docs, as JDBC v2 is an internal name. For the end user it's the same driver with some behavioural changes from version
0.8.0
. - I didn't find a list of changes and unsupported features in JDBC starting from
0.8.0
(Transactions, for example), which is important to highlight. It's not necessarily to follow the same format, but you can see how it was done in the same JDBC driver previously https://github.com/ClickHouse/clickhouse-java/tree/v0.4.0/clickhouse-jdbc#upgrade-to-032
The tricky part here is the difference between a SaaS product (always showing latest rather than maintaining state) and traditional SW documentation. But I agree with this sentiment, it also might be worth us exploring at this point how do we do "versioning" of the documentation rather than having "extra pages" - like having a version drop down and corresponding version in the URL. Maybe we need to consider something like having JavaDocs being the "source of truth" of functionality? At least one of the immediate things we should do is treat the sidebar as the "ideal customer journey" rather than an index. We can link in the main doc to the v1 documentation until it's deprecated.
I think rather than listing out all unsupported features, it would be more beneficial for a user to have a "migration guide" that has this information in and alternatives to achieving similar functionality if applicable. |
@mshustov I think separating documents is good because:
|
|
||
## More Information | ||
For more information, see our [GitHub repository](https://github.com/ClickHouse/clickhouse-java) and [Client-V2 documentation](/docs/en/integrations/language-clients/java/client-v2.md). | ||
``` |
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 see a few issues with docs
label. should we address them from the very beginning? https://github.com/ClickHouse/clickhouse-java/issues?q=is%3Aissue%20state%3Aopen%20label%3Adocs%20label%3Ajdbc-v2
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.
we can do it a in follow-up
sidebar_label: JDBC V2 | ||
sidebar_position: 4 | ||
keywords: [clickhouse, java, jdbc, driver, integrate] | ||
description: ClickHouse JDBC driver V2 |
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.
But I agree with this sentiment, it also might be worth us exploring at this point how do we do "versioning" of the documentation rather than having "extra pages" - like having a version drop down and corresponding version in the URL.
@laeg What about using the client versioning? There will be 2 pages:
- description: ClickHouse JDBC driver > v0.8.x (or ClickHouse JDBC driver latest)
- description: ClickHouse JDBC driver v0.7.x
We can manually add more pages if necessary and they always transparently mapped to JDBC release version
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.
yeah i would prefer if we aligned it more to release versions rather than internal code versions.
did we look into whether we could do something more elegant for versioning the docs?
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.
did we look into whether we could do something more elegant for versioning the docs?
I didn't manage to find a solution in 30min.
Co-authored-by: Mikhail Shustov <[email protected]>
| Named Parameters | Not part of the JDBC spec | | ||
| Stream-based PreparedStatements | Early version of the driver allowed for non-jdbc usage of PreparedStatements - if you desire such options, we recommend looking at [Client-V2](/docs/en/integrations/language-clients/java/client-v2.md) and its [examples](https://github.com/ClickHouse/clickhouse-java/tree/main/examples/client-v2). | | ||
|
||
### Handling Dates, Times, and Timezones |
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.
❤️ to this section.
A minor ask: could you move it to Supported data types
section?
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 last thing, I'd like to sort out is versioning in https://github.com/ClickHouse/clickhouse-docs/pull/3071/files#r1925045569
and (minor)moving data/time concerns to Supported types
section
adding my comment again:
we can do the same for java v1 & v2 documentation |
Summary
Added docs to support the V2 version (while keeping the V1 version of the docs)
Closes ClickHouse/clickhouse-java#1480
Checklist