huxi / rusty_ulid Goto Github PK

Can I ask you what's the difference between this and https://github.com/dylanhart/ulid-rs?

Thanks for creating such a great utility. I love how well organized and especially well documented it is.

Would there be interest in an API for this which provides a next_monotonic but does so using a thread-safe context and the value is updated atomically? I understand that this might be a major departure from the scope of this crate, which is why I'm asking. I'm happy to make the enhancements, but only if you are interested in such a scope change/increase.

If so, here's my thoughts:

1. Ulid isn't actually guaranteed to be monotonically increasing: If 2 Id's are generated in the same millisecond, their date bits will be equal, but the random bits could be ordered incorrectly.
   ulid/spec#11
2. If we want true monotonicity, we need to have a counter whose significant bits are higher than the random bits.
3. So we steal 12 bits from random to create a counter. (to legacy ULIDs, this is still valid "random" data)
4. We atomically compare and swap the date of the previously generated Ulid.
5. To do so, it needs to live in its own 64bit word that is aligned.
6. Luckily, we don't need the entire previous Ulid, just the timestamp that was used to create it.
7. I was thinking we could wrap the Timmestamp in a simple struct that is just UlidContext (and it would need to be wrapped in an Arc in order to be passed across threads safely.
8. The Timestamp would be shifted 12 bits to the left to allow for the counter.
9. So a thread-friendly next_monotonic function might be:

    fn threadsafe_next_monotonic(ctx: Arc<UlidContext>) -> Option<Ulid> {
        let mut next = unix_epoch_ms() << 12;
        let mut current = ctx.0.load(Ordering::Acquire);
        let mut counter = current >> 48; 
        while next != ctx.0.compare_and_swap(current, next, Ordering::Acquire) {
          current = ctx.0.load(Ordering::Acquire); 
          next = current + 1;
        }
        return ulid_with_context_and_rng(ctx, &mut rand::thread_rng());
    }

This isn't correct code, and I'm sure the algo could be made to be safer and more efficient.
That's the basic idea, though.
It would be a bit slower than the non-threaded version, but, that is usually the case.

Edit : Man I really typo'd the crap out of this post. I need to get more sleep

Thank you for your work on this library.

Would you have any feedback on the performance difference in Postgres DB for primary key on a table with 1 million records for read, write sorting between:

BIGINT
UUID v7
ULID

Particularly on multiple table join queries with either of above as PK and FK

Ulid should implement Serde's Serialize and Deserialize as an optional feature.

This will enhance the library's interoperability per Rust API Guidelines: Data structures implement Serde's Serialize and Deserialize