Closed absar closed 1 year ago
Actually I do plan to add it soon. I found it a little while ago and have it bookmarked. Just haven't gotten around to implementing it.
I was doing a deep dive into unique IDs. And was also considering making new libraries for ulid, hexoid, and a few others.
I'll keep you posted about it as I get closer through this issue
I was doing a deep dive into unique IDs. And was also considering making new libraries for ulid, hexoid, and a few others.
I was researching as well and found only one reasonable candidate for database IDs in dart, which is ULID the only issues are lack of documentation, BSD-style license, it does not have big community support which makes it a bit risky to use at least for now
I'll keep you posted about it as I get closer through this issue
Great! thanks, looking forward to it
Just wanted to give you a heads up. https://github.com/Daegalus/dart-uuid/tree/uuidv6 has a working uuid v6 and v7. It is not 100% ready and no docs (but i updated examples and have tests). I need to get in touch with the draft authors to see if there are any test samples they might have that I could potentially use to verify my code.
Also, Dart's microseconds from Epoch maximum (and milliseconds for Dart2js because JS doesn't support micro or nano seconds) makes it so I can't compare it easily to the Zig and Python prototype implementations, as they all rely on and use nanoseconds. I use microseconds for v7, as I tested the dart2js output and for JS side it takes milliseconds and multiplies it by 1000. Which works fine and is supported. (cant do the same for v1 and v6 because converting to Gregorian time pushes hits integer limits when shifting things around.
I plan to add v8 support also. There is a fairly major refactor in that branch too of the organization of the library, should be easier to poke around.
You are welcome to play around with it, but I encourage you to not use it in any production applications.
That was fast thanks, I will definitely give it a try and do some tests
Hey, just an update. The branch has been updated to Draft 3 and has all the fixes and such of master. I redid uuidv7 to work more accurately to the new draft, and added a custom UUIDv8 to try also. Since UUIDv8 is so nebulous its probably unique to my implementation. UUIDv6 didn't have any changes.
Is there any blocker for this draft ? I'm currently building against the git repo with a fixed commit.
Is there any blocker for this draft ? I'm currently building against the git repo with a fixed commit.
Not really. I was waiting for the next Draft to hit to merge this into master and cut a release, but it seems the Draft is moving into a new phase related to making it a final official RFC.
So I will try to find some time this weekend to clean it up, merge it, and cut a 4.0 beta release.
I apologize for the delay.
I have released 4.0.0-beta1, please open any bugs as new issues. I will close this issue now that it is merged.
Thanks for your work!
Time to move this out of beta?
Ya I think it's safe to say the current Draft v6-8 spec isn't going to change anymore in any significant way, and I was waiting for v6 to be out of draft.
I'll do a release sometime this week, thanks for the reminder to check in.
Do you have any plans to implement UUIDv7, although it's still a recent draft? It would be a nice addition to the library and will solve the long standing issue with previous UUID variants, which are not suitable to generate time-based, sortable unique identifiers to use as database keys Here is the link to the draft UUIDv7