Skip to content

docs(timeseries): Python and Rust binary ingest, and what JSON ingest… - #82

Open
JosteinGj wants to merge 2 commits into
masterfrom
docs/sdk-timeseries-ingest
Open

JosteinGj wants to merge 2 commits into
masterfrom
docs/sdk-timeseries-ingest

Conversation

@JosteinGj

Copy link
Copy Markdown
Contributor

… really does

Both SDKs have insert_datapoints_binary on main (Python on the sync client), so the binary sections gain Python and Rust tabs. JSON ingest in those clients sends up to 100 000 datapoints per request, four at a time, and does not retry; the 10 000-per-request and retry-with-backoff claims are Java's. Every series that later takes decimals sets its value type, since Python defaults to bigint and Rust to float, and Python can only set bigint, float and text. The Python filter takes keywords; TimeSeriesFilterForm is a Rust type only.

JosteinGj and others added 2 commits September 17, 2026 14:03
… really does

Both SDKs have insert_datapoints_binary on main (Python on the sync client), so
the binary sections gain Python and Rust tabs. JSON ingest in those clients
sends up to 100 000 datapoints per request, four at a time, and does not retry;
the 10 000-per-request and retry-with-backoff claims are Java's. Every series
that later takes decimals sets its value type, since Python defaults to bigint
and Rust to float, and Python can only set bigint, float and text. The Python
filter takes keywords; TimeSeriesFilterForm is a Rust type only.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Signed-off-by: jgjesdal <jostein@intellistream.ai>
…same caps

The ingest caps are the API's and bind every client; nothing about them is
Java's. Java's 10 000 is its default batch size, Python and Rust send up to
100 000 datapoints per request, and all three stay inside the caps. Python and
Rust do retry: with durable buffering on, a transient failure (429, 5xx,
network, 401/403) is written to the spool and sent again, oldest first, by the
next ingest call. Only with buffering off is the first failed request the
call's error.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Signed-off-by: jgjesdal <jostein@intellistream.ai>
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.

1 participant