Skip to content
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

add_record_raw has poor documention, may not be usable #30

Open
njaard opened this issue Dec 18, 2023 · 2 comments
Open

add_record_raw has poor documention, may not be usable #30

njaard opened this issue Dec 18, 2023 · 2 comments

Comments

@njaard
Copy link
Owner

njaard commented Dec 18, 2023

I had problems with it myself in #28

@ettom
Copy link
Contributor

ettom commented Dec 18, 2023

I actually came across another usecase for passing around a Vec<u8>. I want to create a trait method which returns the result of record(). This doesn't seem directly possible due to impl Trait not being a valid return value. I figure I should be able to pass the output of RecordBuilder::store() to add_record_raw by replicating this logic here?
https://github.com/njaard/sonnerie/blob/172c301950cdde42bd70bd44b3c6d58373410fc1/src/write.rs#L227C1-L251C5

Or actually just

buf.write_u64::<BigEndian>(1.1e18 as u64).unwrap();
record.store(&mut buf);

should be enough?

@njaard njaard changed the title add_record_raw has poor documention, may not be unusable add_record_raw has poor documention, may not be usable Dec 18, 2023
@njaard
Copy link
Owner Author

njaard commented Dec 18, 2023

Yes to replicating the logic in that function you linked to.

Just storing that 1.1e18 (to represent the timestamp?) isn't enough in the case of storing strings as a payload, because Strings are variable-length encoding.

You can see the length of the entire record is stored as a varint in that case

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

No branches or pull requests

2 participants