6.0.0

Overview

This PR introduces nanosecond support.

This release introduces nanosecond support and, while it supports older servers, it is designed to be used in conjunction with QuestDB 9.1.0 onwards which introduces the TIMESTAMP_NS column type.

What what remains the same

• There are no API changes.
• The protocol_version=1 behaviour remains unchanged.

What's changed

New protocol_version=2 behaviour

If protocol_version>=2, for all timestamp columns (including the designated timestamp column):

• If you add a TimestampMicros timestamp, it will be sent to the server as micros.
• If you add a TimestampNanos timestamp, it will be sent to the server as nanos.
• If you add a datetime library object it will be sent down as nanoseconds.

When writing to QuestDB 9.1.1 or newer and no schema already exists, the server will auto-create any missing timestamp columns using the TIMESTAMP (micros) or TIMESTAMP_NS (nanos) column type matching the client's sent precision.

When sending to QuestDB 9.1.0 instead will always auto-create TIMESTAMP (micros) columns, unless you explicitly configure line.timestamp.default.column.type=TIMESTAMP_NS in server.conf.

Retained protocol_version=1 behaviour

The protocol_version==1 behaviour is retained as before this release:

• Both micros and nanos APIs send as nanos to the server when adding the designated timestamp.
  • By default, for backwards-compatibility, the server will continue to store the data as micros, unless the table was pre-created via SQL.
• Both micros and nanos APIs send as micros to the server when adding any other column timestamps.

Existing schema continues to override

Just as always, if you create a table's schema via a SQL CREATE TABLE command, the server will convert the timestamps to the schema-specified precision. This will happen regardless of the protocol version used by the client.

Practical upgrading advice

• When upgrading, there are no API changes.
• The TIMESTAMP_NS datatype and nanosecond precision timestamps are available from QuestDB 9.1.0, with improved handling in QuestDB 9.1.1 and later.
• Older QuestDB versions which do not support the TIMESTAMP_NS column type will continue to use the TIMESTAMP column type. This change does not break compatibility with these older releases.
• This is a breaking change only if you rely on table or column auto-creation. We encourage you to review your own API usage if you rely on this feature and double-check you're happy with the resulting timestamp precisions.
• The breaking auto-creation behaviour is exposed when upgrading to QuestDB 9.1.1 and later and protocol_version=2 and an updated client library version.

Full Changelog: 5.1.0...6.0.0

5.1.0 (yanked)

Yanked release

There are no reported bugs, but this release has some behaviour and usability inconsistencies with nanoseconds behaviour and 9.1.0 in what precision is used by the server for messages sent by the client between the designated timestamp and other timestamp columns behaving differently. We will release 6.0.0 shortly which will make using nanosecond timestamps more consistent.

Overview

This is a very small release which adds support for nanosecond-precision columns.

Features

From QuestDB 9.1.0 you can use CREATE TABLE SQL statement with TIMESTAMP_NANO column types,
and/or configure the database to use nanosecond precision designated timestamp columns by setting the line.timestamp.default.column.type=TIMESTAMP_NANO config option in server.conf.

This client release adds support for sending timestamps to the server without loss of precision.

The change is backwards compatible with older QuestDB versions and does not introduce new APIs.

Full Changelog: 5.0.0...5.1.0

5.0.0

Overview

This release adds a new protocol version that brings support for N-dimensional arrays and faster serialization of doubles.

It stabilizes the features first introduced with version 5.0.0-rc1.

Features

• You can now ingest the ARRAY datatype when connected to QuestDB 9.0.0 or newer. It uses a new protocol_version=2.
• This new protocol version is auto-negotiated when using HTTP and needs to be enabled manually for ILP/TCP.
• The new protocol version also serializes doubles (f64) as binary for better performance.
• Updated to the latest snapshot of the https://www.ccadb.org/ root TLS certificates by updating the webpki-roots dependency.
• Internally, we've upgraded to the latest ureq Rust library version 3 to perform HTTP requests.

Bug Fixes

• Fixed a Windows ILP/TCP bug where some rows could be lost when the client shuts down the connection.

Breaking Changes

• Previously, you could peek into the serialized state of a Buffer object and it would expose a UTF-8 string.
  Since protocol version 2 is now binary, the exposed data is now binary for protocol version 2
  while it remains UTF-8 for protocol version 1. The C, C++ and Rust APIs have been changed to return a view into the buffered bytes.

Rust

There are also a few Rust-specific changes.

• Added optional integration with the ndarray crate via ndarray feature flag.
• Added support for the aws-lc cryptographic backend for TLS and TCP auth. You can select it via feature flags. The AWS-LC backend is mutually exclusive with the Ring backend.
• You can now also check if a buffer is ready to be sent via the .check_can_flush() method (Thank you @ischeinkman).
• You can now selectively disable compiling support for ILP/TCP via feature flags.
• Thus, the ilp-over-http feature flag is removed: Use the sync-sender-tcp or sync-sender-http (or both) feature flags as needed.

Full Changelog: 4.0.5...5.0.0

4.0.5

What's Changed

This release ships a performance improvement which avoids memory allocations when setting a marker on a buffer object.
Details are in #108

Full Changelog: 4.0.4...4.0.5

5.0.0-rc1

Overview

This is a pre-release version that adds a new protocol version which adds new features.

Features

• When using protocol 2 (which is automatically enabled if connecting over HTTP and the server supports it):
  • Sending floating point data is now done over binary with reduced overhead
  • New added support for ingesting 64-bit float multi-dimensional arrays targeting the upcoming ARRAY datatype in QuestDB.
• In Rust, we've optionally (see feature flag) added integration for sending arrays from the ndarray crate.
• Internally, we've upgraded to the latest ureq rust library version 3 to perform HTTP requests.
• In Rust we've also optionally added the aws-lc cryptographic backend for TLS and TCP auth. You can select it via feature flags.
• We have internally updated the webpki-roots crate which uses an updated set of root TLS certificates.
• You can now also check if a buffer is ready to be sent via the .check_can_flush() method (Thank you @ischeinkman).

Breaking Changes

• Previously, you could peek into the serialized state of a Buffer object and it would expose a UTF-8 string.
  Since protocol version 2 is now binary, the APIs have been updated and the exposed data is binary for protocol version 2
  while it remains UTF-8 for protocol version 1.

Full Changelog: 4.0.4...5.0.0-rc1

4.0.4

What's Changed

In this release we've fixed a C++ build issue due to an incompatibility in the newest release of the Rust tool rustup.

• CMake "corrosion" library upgraded to 0.5.1, fixing C++ build issues.
• Various minor documentation fixes.

Full Changelog: 4.0.3...4.0.4

4.0.3

What's Changed

In this release, we have addressed a significant issue related to a version conflict with rustls library, which was causing compilation errors in Rust projects using our client. Here are the detailed changes:

• ureq library pinned to 2.9. This is a workaround for algesten/ureq#765
• Enforce request timeout greater than zero. #74

Full Changelog: 4.0.2...4.0.3

4.0.2

What's Changed

• bug: HTTP timeout wasn't applied to the TCP connection phase

Full Changelog: 4.0.1...4.0.2

4.0.1

What's Changed

• Significant improvement in the Rustdoc documentation
• ilp-over-http is now a default feature flag, improving the quick start experience

Full Changelog: 4.0.0...4.0.1

4.0.0

Features

This release introduces a number of changes, including major new features and a few breaking changes in the Rust, C and C++ APIs.

Introduction of ILP over HTTP Support

The library now supports InfluxDB Line Protocol (ILP) over HTTP in addition to the existing TCP protocol.

• ILP/HTTP allows for better error feedback and control over transactions and is the recommended for both existing and new users.
• ILP/HTTP introduces basic (username/password) and token (bearer) authentication.

// C++
auto sender = questdb::ingress::sender::from_conf("http::addr=localhost:9000;token=auth_token;");

Configuration via String or Environment Variable

Users can now configure the client by passing a configuration string or via an environment variable (QDB_CLIENT_CONF). This provides a more flexible and convenient way to configure the client. This new approach is being adopted for all our client libraries.

// Rust
let sender = Sender::from_conf("tcp::addr=localhost:9009;")?

The builder/opts APIs remain available.

Transaction Support

The library introduces transactional flushes for ILP over HTTP, allowing users to ensure that all rows in a flush request refer to the same table, treating the request as a single transaction. This feature is allows for use cases where ingestion atomicity is required.

Reliability Enhancements

The ILP over HTTP implementation includes features like configurable request timeouts, retry mechanisms, and minimum expected throughput settings to improve the performance and reliability of data transmission.

Buffer Row Count

You can ask the buffer how many rows it has recorded by calling its .row_count() method.

Breaking Changes

.connect() renamed to .build()

When using the builder/opts API, the connect method has been renamed to build.

This is because when connecting via HTTP, the connection to the database is made lazily at the first flush.

TCP Auth API Changes

The ILP/TCP .auth(username, token, token_x, token_y) method which took for parameters has been expanded to four different settings.

From conf:

// Rust
let sender = Sender::from_conf("tcps::addr=localhost:9009;username=u;token=t;token_x=x;token_y=y;");

Programmatically:

// Rust
let sender = SenderBuilder::new(Protocol::Tcps, "localhost", 9009)
    .username("u")?
    .token("t")?
    .token_x("x")?
    .token_y("y")?
    .build()?;

TLS configuration parameters

The .tls(...) API has been removed and replaced with:

• tls_ca which takes an enum (webpki, os, webpki+os, pem_file)
• tls_roots replaces the old tls_ca API.
• tls_verify(false) replaces the older insecure_skip_verify API.

net_interface -> bind_interface

The TCP-only setting for binding the outbound network interface has been renamed to bind_interface.
This feature is no longer available when using HTTP. Raise an issue if this is something you require.

Full changelog: 3.1.0...4.0.0