ClickHouse / ClickHouse/clickhouse-java
[client-v2] Allow QuerySettings in POJO queryAll overloads
- Dominant language
- Java
- Stars
- 1.6k
- Forks
- 636
- Avg merge
- 2d 16h
- Merged PRs (30d)
- 28
Description
Hi! This is my first issue in this repository, so apologies if I did not formulate the idea perfectly.
I'm also not completely sure whether this API change is technically appropriate or possible. There may be a reason why `QuerySettings` cannot or should not be passed to the POJO `queryAll` overloads. If so, I would be happy to understand the reasoning.
### Description
The experimental POJO `queryAll` API currently does not provide an overload that accepts `QuerySettings`.
Current overloads:
```java
queryAll(String sqlQuery, Class clazz, TableSchema schema)
queryAll(
String sqlQuery,
Class clazz,
TableSchema schema,
Supplier allocator
)
```
Internally, the method creates its own QuerySettings:
```java
QuerySettings settings =
new QuerySettings()
.setFormat(ClickHouseFormat.RowBinaryWithNamesAndTypes);
```
Because of that, callers cannot provide query/server settings such as:
- limit
- page
- max_execution_time
- query id
- database
- other operation-level server settings
At the same time, queryAll for GenericRecord already accepts QuerySettings and copies the supplied settings while forcing the response format to RowBinaryWithNamesAndTypes.
It would be useful if the POJO overloads supported the same behavior.
Proposed API
For example:
```java
public List queryAll(
String sqlQuery,
Class clazz,
TableSchema schema,
QuerySettings settings
)
public List queryAll(
String sqlQuery,
Class clazz,
TableSchema schema,
QuerySettings settings,
Supplier allocator
)
```
The response format should still be controlled internally by queryAll, since POJO deserialization depends on RowBinaryWithNamesAndTypes.
In other words, the provided settings could be copied and then:
```java
requestSettings.setFormat(
ClickHouseFormat.RowBinaryWithNamesAndTypes
);
```
This would keep POJO deserialization safe while allowing callers to use settings such as pagination, execution limits, query id, database, etc.
Why
This would make the POJO queryAll API consistent with the existing GenericRecord queryAll API and would avoid forcing callers to reimplement the POJO deserialization path only to pass custom QuerySettings.
Contributor guide
Assessment
This issue has not been assessed yet.