feat: add custom node ids #107
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
knock knock neo … |
I think that could be an error in the documentation of [NewDCEGroup](https://github.com/google/uuid/blob/281f560d28af7174109514e936f94c2ab2cb2823/dce.go#L53) and [NewDCEPerson](https://github.com/google/uuid/blob/281f560d28af7174109514e936f94c2ab2cb2823/dce.go#L45)
Fix reamde to no longer say this is experimental. The API is not going to change.
{xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Resolves issue google#24
* Resolved code issues of gofmt and golint Code quality: https://goreportcard.com/report/github.com/google/uuid * Fix typo * Update comment
Now it's easier to set breakpoint on error for debugging.
* Fixed race in NewUUID() * Remove unnecessary variable
…oogle#69) * Add benchmarks for different kinds of invalid UUIDs Also add a test case for too-short UUIDs to ensure behavior doesn’t change. * Use a custom error type for invalid lengths, replacing `fmt.Errorf` This significantly improves the speed of failed parses due to wrong lengths. Previously the `fmt.Errorf` call dominated, making this the most expensive error and more expensive than successfully parsing: BenchmarkParse-4 29226529 36.1 ns/op BenchmarkParseBadLength-4 6923106 174 ns/op BenchmarkParseLen32Truncated-4 26641954 38.1 ns/op BenchmarkParseLen36Corrupted-4 19405598 59.5 ns/op When the formatting is not required and done on-demand, the failure per se is much faster: BenchmarkParse-4 29641700 36.3 ns/op BenchmarkParseBadLength-4 58602537 20.0 ns/op BenchmarkParseLen32Truncated-4 30664791 43.6 ns/op BenchmarkParseLen36Corrupted-4 18882410 61.9 ns/op
Zero allocation by using non-pointer error. related google#69 name old time/op new time/op delta ParseBadLength-16 15.4ns ± 0% 3.5ns ± 0% ~ (p=1.000 n=1+1) name old alloc/op new alloc/op delta ParseBadLength-16 8.00B ± 0% 0.00B ~ (p=1.000 n=1+1) name old allocs/op new allocs/op delta ParseBadLength-16 1.00 ± 0% 0.00 ~ (p=1.000 n=1+1)
Added a single period so that the documentation doesn't look weird. Boy, I hope the tests pass.
* hash.go hash error covered and linter error fixed Error covered without change function definition * Update hash.go
* added utility func * updated docs & function call
Updates the README to fix the link to the RFC. Fixes google#92.
This PR replaces `godoc.org` with `pkg.go.dev` in README.
* feat: add uuid slice type with strings convenience method * test: benchmark new UUIDs.Strings() feature * docs: improve comments on UUIDs * fix: typos in UUIDs strings benchmark
…validate, strings. (google#135)
🤖 I have created a release *beep* *boop* --- ## [1.4.0](https://togithub.com/google/uuid/compare/v1.3.1...v1.4.0) (2023-10-26) ### Features * UUIDs slice type with Strings() convenience method ([google#133](https://togithub.com/google/uuid/issues/133)) ([cd5fbbd](https://togithub.com/google/uuid/commit/cd5fbbdd02f3e3467ac18940e07e062be1f864b4)) ### Fixes * Clarify that Parse's job is to parse but not necessarily validate strings. (Documents current behavior) --- This PR was generated with [Release Please](https://togithub.com/googleapis/release-please). See [documentation](https://togithub.com/googleapis/release-please#release-please).
* add uuid version 6 and 7 * fix comment
* feat: Validate UUID without creating new UUID * fix: update comment
Co-authored-by: release-please[bot] <55107282+release-please[bot]@users.noreply.github.com>
add Max uuid
* Monotonicity in UUIDv7 * fix Monotonicity * fix comment * Monotonicity 2 * lock * fix comment * fix comment
* The top level permission for github workflows were set to be content read Signed-off-by: Joyce Brum <[email protected]>
* fix to use MustParse * use MustParse(...) inseted of Must(Parse(...)) --------- Co-authored-by: Noah Dietz <[email protected]> Co-authored-by: bormanp <[email protected]>
* feat: add Compare function * fix comment
* upd links to draft * RFC 4122 -> 9562 * add extra comment --------- Co-authored-by: bormanp <[email protected]>
* feat: add error types * fix: broken backward compatibility
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In the current implementation, the generation of version 1 UUIDs using distinct node ids is only possible by sequentially calling "SetNodeID(…); NewUUID()" for each UUID to generate.
There also is no sort of locking for this workflow, so we might experience race conditions when generating UUIDs for distinct node ids simultaneously.
Additionally RFC-4122 section 4.5 suggests to set the u/m bit to 1, when using custom node ids in order to reliably avoid collisions with UUIDs created for node ids which are based on IEEE 802 addresses. This is not (and should not being) checked within the global SetNodeID(...) func.
So I decided to add a CustomNodeId type which enables this kind of usage in a clean way.