-
Notifications
You must be signed in to change notification settings - Fork 19
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
base: main
Are you sure you want to change the base?
Conversation
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) | ||
} |
There was a problem hiding this comment.
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" |
There was a problem hiding this comment.
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.
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) | ||
} |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this 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.
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