feat(rust): add support to u64 and u256#100
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.
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.
| 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.
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.
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.
Just remembered.. might want to reserve the exact additional needed bytes here too.
amunra
left a comment
amunra
left a comment
There was a problem hiding this comment.
Thanks!
I've provided some pointers on how to move this PR forward towards approval.
3 participants
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