Skip to content

feat(rust): add support to u64 and u256 #100

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

juanAngel
Copy link

Adds support for these types on the client. However, you'd still need to create the table first.

It's a simple change that makes life easier.

There's also an open issue regarding this:

#75

@CLAassistant
Copy link

CLAassistant commented May 6, 2025

CLA assistant check
All committers have signed the CLA.

Comment on lines +940 to +951
pub fn column_u64<'a, N>(&mut self, name: N, value: u64) -> Result<&mut Self>
where
N: TryInto<ColumnName<'a>>,
Error: From<N::Error>,
{
self.write_column_key(name)?;
let mut buf = itoa::Buffer::new();
let printed = buf.format(value);
self.output.extend_from_slice(printed.as_bytes());
self.output.push(b'i');
Ok(self)
}
Copy link
Collaborator

Choose a reason for hiding this comment

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

It would be misleading for the API to accept a datatype that the server does not.
If you need to serialize a u64, best do a checked cast and then call column_i64.

@@ -32,6 +32,7 @@ rustls = { version = "0.23.25", default-features = false, features = ["logging",
rustls-native-certs = { version = "0.8.1", optional = true }
webpki-roots = { version = "0.26.8", default-features = false, optional = true }
chrono = { version = "0.4.40", optional = true }
hex = "0.4.3"
Copy link
Collaborator

@amunra amunra May 6, 2025

Choose a reason for hiding this comment

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

Don't need the external dep.
Explained faster alternative later.

Comment on lines +953 to +962
pub fn column_long256<'a, N>(&mut self, name: N, value: [u8; 32]) -> Result<&mut Self>
where
N: TryInto<ColumnName<'a>>,
Error: From<N::Error>,
{
self.write_column_key(name)?;
let ser = format!("0x{}i", hex::encode(value));
self.output.extend_from_slice(ser.as_bytes());
Ok(self)
}
Copy link
Collaborator

@amunra amunra May 6, 2025

Choose a reason for hiding this comment

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

Good start! This is indeed a missing feature and a very welcome contribution.

The long256 encoding looks correct.
https://questdb.com/docs/reference/api/ilp/columnset-types/#long256

For us to consider the PR, it should include tests and a C and C++ API and tests against a live DB (system_test dir). Happy to help if you need assistance with anything here.

As per this function itself, it would need minor tweaking to avoid allocating memory.
In other words, calling format! here isn't really something we'd want to do.

Given that the number is a fixed-size slice, you should be able to just call write!(&mut self.output, "0x{:x}{:x}{:x}{:x}i", .., .., .., ..). This also drops the dependency on hex and the additional dynamic slice size conditional that carries with it.

API docs should include any byte-order considerations.
The representation should align with bigint's H256: https://docs.rs/ethereum-bigint/latest/bigint/struct.H256.html - The questdb-rs crate should not depend on bigint but it should ideally link to it in docs and provide a basic example.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Just remembered.. might want to reserve the exact additional needed bytes here too.

Copy link
Collaborator

@amunra amunra left a comment

Choose a reason for hiding this comment

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

Thanks!
I've provided some pointers on how to move this PR forward towards approval.

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.

3 participants