Skip to content

Drop the timeseries tableEngine field, which the api is removing - #115

Merged
olavgg merged 1 commit into
mainfrom
chore/remove-timeseries-table-engine
Sep 11, 2026
Merged

Drop the timeseries tableEngine field, which the api is removing#115
olavgg merged 1 commit into
mainfrom
chore/remove-timeseries-table-engine

Conversation

@JosteinGj

Copy link
Copy Markdown
Contributor

No read has returned tableEngine since the api marked it @JsonIgnore: which ClickHouse engine backs a series is an internal storage decision, not part of the entity. The field was kept anyway because create still accepted it, so it was write-only in practice and always None on the way back. The api is now removing it outright, which takes that last reason with it - and since request bodies are read strictly, a body still naming it would be a 400.

Gone from TimeSeries and both its constructors, from the PyO3 constructor and getter, from the stub, and from the tests that pinned it as always-None. Also from the node serialization test's foreign/own field lists, so a timeseries no longer claims a field it does not have.

Safe to land in either order relative to the api: nothing in this SDK ever set the field (there is no setter, and skip_serializing_if kept it off the wire), and responses stay lenient, so a response that still carries it deserializes fine. src/resources/tests.rs keeps its reference to the @JsonIgnore change in d70b57ad - that is a record of what the parity test found, still accurate.

No read has returned tableEngine since the api marked it @JsonIgnore: which
ClickHouse engine backs a series is an internal storage decision, not part of
the entity. The field was kept anyway because create still accepted it, so it
was write-only in practice and always None on the way back. The api is now
removing it outright, which takes that last reason with it - and since request
bodies are read strictly, a body still naming it would be a 400.

Gone from TimeSeries and both its constructors, from the PyO3 constructor and
getter, from the stub, and from the tests that pinned it as always-None. Also
from the node serialization test's foreign/own field lists, so a timeseries no
longer claims a field it does not have.

Safe to land in either order relative to the api: nothing in this SDK ever set
the field (there is no setter, and skip_serializing_if kept it off the wire),
and responses stay lenient, so a response that still carries it deserializes
fine. src/resources/tests.rs keeps its reference to the @JsonIgnore change in
d70b57ad - that is a record of what the parity test found, still accurate.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Signed-off-by: jgjesdal <jostein@intellistream.ai>
@JosteinGj
JosteinGj requested a review from olavgg September 11, 2026 12:01
@olavgg
olavgg merged commit b93d086 into main Sep 11, 2026
18 checks passed
@olavgg
olavgg deleted the chore/remove-timeseries-table-engine branch September 11, 2026 23:26
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