nebkor
/
blog
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

tweak

This commit is contained in:
Joe Ardent 2023-07-31 07:28:17 -07:00
parent 51ff082cbf
commit 7b3cbc9dad
1 changed files with 3 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
content/sundries/presenting-julids/index.md
View File

@ -278,7 +278,7 @@ those crates! Feel free to steal code from me any time!
[name](https://gitlab.com/nebkor/julid/-/blob/2484d5156bde82a91dcc106410ed56ee0a5c1e07/Cargo.toml#L24)
is just "julid"; that's how you refer to it in a `use` statement in your Rust program.
[^counter idea]: Sticking the counter bits after the timestamp bits was stolen from
[^counter idea]: Putting the counter bits after the timestamp bits was stolen from
<https://github.com/ahawker/ulid/issues/306#issuecomment-451850395>, though they use only 15 bits
for the counter, due to each character in the string encoding representing five bits, and using
three whole characters for the counter. That gives them one more random bit than Julids, and
@ -289,8 +289,8 @@ those crates! Feel free to steal code from me any time!
integer](https://gitlab.com/nebkor/julid/-/blob/2484d5156bde82a91dcc106410ed56ee0a5c1e07/src/julid.rs#L11-12)
to ensure that IDs generated within the same millisecond have incremented counters, but that
atomic counter is not global; calling `Julid::new()` in Rust and `select julid_new()` in SQLite
will not be aware of each others' counters. I just make sure to only generate them inside the
DB.
would be as though they were generated on different machines. I just make sure to only generate
them inside the DB.
[^my computer]: According to the output of `lscpu`, my computer has an "AMD Ryzen 9 3900X 12-Core
Processor", running between 2.2 and 4.6 GHz. It's no slouch!