Skip to content

[Integration Spec] Update integration-client.md - #3170

Open
chernser wants to merge 11 commits into
mainfrom
09/26/26/int_spec_client_update
Open

chernser wants to merge 11 commits into
mainfrom
09/26/26/int_spec_client_update

Conversation

@chernser

@chernser chernser commented Sep 30, 2026 •

Copy link
Copy Markdown
Contributor

Summary

  • Update integration-client.md
  • Changes structure to be more consistent
  • Reorganizes sections
  • Resolves follow up comments

Previous Comments

Checklist

Delete items not relevant to your PR:

  • Closes #
  • Unit and integration tests covering the common scenarios were added
  • A human-readable description of the changes was provided to include in CHANGELOG
  • For significant changes, documentation in https://github.com/ClickHouse/clickhouse-docs was updated with further explanations or tutorials

@chernser
chernser requested a review from mzitnik as a code owner September 30, 2026 06:19
@chernser chernser changed the title Update integration-client.md [Integration Spec] Update integration-client.md Sep 30, 2026

@laeg laeg left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

some changes that would be great to address please mate!

## Artifacts
This guide names only the properties relevant to each step. The exhaustive lists live in [`ClientConfigProperties`](../client-v2/src/main/java/com/clickhouse/client/api/ClientConfigProperties.java), and the official docs. Configuration splits into two groups:
- **Init configuration** — set once using [Client.Builder](/client-v2/src/main/java/com/clickhouse/client/api/Client.java) methods: endpoint, connection pool size, authentication, TLS. Covered in Steps 1–4.
- **Operation configuration** — set via `com.clickhouse.client.api.Client` method like `com.clickhouse.client.api.Client.Builder.setAccessToken`.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: should we say when these are covered like the previous bullet?

isnt setAccessToken a client instantiation method? maybe this should be the init config example and operations config updateAccessToken? Or InsertSettings/QuerySettings might be more appropriate for per request

| `connection_pool_enabled` (`.enableConnectionPool()`) | Enable/disable HTTP connection pooling (keep enabled). | `true` |
| Property | Builder method | Purpose |
|-------------------------------|-------------------------------------|-------------------------------------------------------------------------------------------|
| `max_open_connections` | `.setMaxConnections()` | Maximum open HTTP connections per server endpoint. Size set from parallelism guidance above.|

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I liked that we had the defaults included previously and a recommendation

Also thinking about the type of folks grabbing this, I think we should include back in a baseline example that folks can copy and paste:

public Client.Builder createBaseClient() {
    return new Client.Builder()
        .addEndpoint("https://your-host:8443")
        .setUsername("default")
        .setPassword("secret")
        .setMaxConnections(50)
        .setConnectionRequestTimeout(5, TimeUnit.SECONDS)
        .setKeepAliveTimeout(60, TimeUnit.SECONDS)
        .setConnectionReuseStrategy(ConnectionReuseStrategy.FIFO);
}

- A table schema cache
- The POJO serialization/deserialization registry
- Optional client-wide session and settings defaults
The [com.clickhouse.client.api.Client](/client-v2/src/main/java/com/clickhouse/client/api/Client.java) is library interface object for most interactions with it:

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The usage focused list is great but I liked that before we explained what the client owns, it helped build the mental model to help partners understand why it should be shared.

Can we keep both? usage list first for "what can I do with it" and then "the client manges" list for "why does it matter how i instantiate it"


In the Java Client a "connection" is an **HTTP connection borrowed from the internal pool**, not a long-lived database session. Each operation borrows a connection, sends a request, streams the response, and returns the connection to the pool.

### Sockets Configuration

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: should we consider folding this back into the Operational Timeouts (h4 instead of h3) so it is correlated to the above.


Database data types are mapped to Java types by the reader or writer and generally follow similar rules across formats (though custom or format-specific readers and writers may use different mappings).

Next read the official client documentation regarding [data types mapping](/docs/clickhouse-docs/client.mdx#data-types). Client API is built around JDK native data types to make

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe this link wont work for folks, can we add the published link:

[ClickHouse to Java data type mapping](https://clickhouse.com/docs/integrations/language-clients/java/client#data-types)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants