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 "AtTime" generators for V1, V6, and V7 #142

Merged
merged 5 commits into from
Aug 11, 2024

Conversation

kohenkatz
Copy link
Contributor

This PR implements the request in #84 to be able to create UUIDs at specific known timestamps, in addition to the current time.

Although that request only mentions UUIDv1, this PR also includes the other two time-based UUID versions, namely v6 and v7.

To prevent code duplication, this PR reimplements NewV1, NewV6, and NewV7 to each call their respective NewV<X>AtTime with the provided EpochFunc, which defaults to providing the current time.

This PR will remain a draft until I have time to write some tests...

Copy link

codecov bot commented May 13, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 100.00%. Comparing base (190948b) to head (484207c).

Additional details and impacted files
@@            Coverage Diff            @@
##            master      #142   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files            5         5           
  Lines          447       459   +12     
=========================================
+ Hits           447       459   +12     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@cameracker
Copy link
Collaborator

cameracker commented May 13, 2024

Nice. Looks good so far. I think it was the right call to add some additional functions. As a mega nit, what do you think of the convention NewVNFromTime()?

@cameracker cameracker self-requested a review May 13, 2024 02:26
@kohenkatz
Copy link
Contributor Author

... what do you think of the convention NewVNFromTime()?

Personally, I like At over From for three reasons:

  1. To me, "From" implies some kind of derivation/modification, while "At" implies that the time is used exactly as-is.
  2. I am used to other frameworks that use At as an indicator that something is a timestamp. For example, Laravel's created_at, updated_at, and deleted_at database fields.
  3. It's slightly shorter to type.

All that said, I really don't care if you want to change it.

generator.go Show resolved Hide resolved
generator.go Show resolved Hide resolved
@cameracker
Copy link
Collaborator

@kohenkatz Dependabot updated the go-setup github action, and I noted we were testing against older versions of go so I took the opportunity to kick them up to latest and latest -1. Might be worth rebasing against master :)

@cameracker
Copy link
Collaborator

@kohenkatz Hi, heads up, I fat fingered the update branch button. You'll want to do a pull when you pick this back up again. Apologies.

@kohenkatz kohenkatz marked this pull request as ready for review August 9, 2024 03:58
@kohenkatz
Copy link
Contributor Author

After what seems like forever, this PR now has tests!

Ready for review once again.

// Generator provides an interface for generating UUIDs.
type Generator interface {
NewV1() (UUID, error)
NewV1AtTime(time.Time) (UUID, error)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd hate to create a new major version for this, but this is pedantically a breaking change if any consumer has their own implementation of the Generator interface.

At a minimum, we should call out that there are 3 new methods on this interface so that consumers will have a pointer to the source of their broken builds.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it is fine to remove from the interface, but that will mean we cannot use the package-level convenience methods, because those operate using DefaultGenerator which uses this interface.

This just means that to use the new methods users will need to create a custom generator.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not against adding the methods to the interface, we just need to decide whether we bump to v6.x or we accept what is technically a breaking change in a v5.x minor release and "fix with words" for any consumers that have their own implementations.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think I'd go with jumping to 6.x. It's not such a big deal to make the change.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Easy enough for this code, but It's a much bigger deal for every consumer to have to update every import to s|v5|v6 😬

Copy link
Contributor Author

@kohenkatz kohenkatz Aug 9, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unfortunately, there's no way for us to know how many consumers are implementing the interface separately. Numbers like that would be very useful to this decision.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

per pkg.go.dev, 749 public things import /v5. I know we have a bunch of internal modules at work that also import it.

I can confirm that we don't have any custom Generator implementations and someone could theoretically check all of those public importers, but it's impossible to know if any non-public consumers will break.

Personally, I feel like the odds are very low that this will actually be a breaking change and we should do a v5.x minor release with a note.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds good to me, but we probably should wait for at least one additional voice.

Copy link
Member

@dylan-bourque dylan-bourque left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The code changes LGTM with the added tests, but we need to make a call on the breaking change to the Generator interface.

Super nit: I think I would prefer to only include the full details for a variant on just one of the New*() functions rather than have it repeated 4X across the 2 New*() functions and the 2 Gen methods.

@cameracker
Copy link
Collaborator

Thank you very much @kohenkatz . Regarding the discussion around releasing it as a minor or major, I think the likelihood of a consumer implementing a custom generator is unlikely due to the extremely niche functionality it offers, and I suspect we won't be impacting much by releasing it as a minor.

@cameracker cameracker merged commit e826b84 into gofrs:master Aug 11, 2024
7 checks passed
@kohenkatz kohenkatz deleted the at_specific_time branch August 11, 2024 17:55
nono referenced this pull request in cozy/cozy-stack Sep 16, 2024
This PR contains the following updates:

| Package | Change | Age | Adoption | Passing | Confidence |
|---|---|---|---|---|---|
| [github.com/gofrs/uuid/v5](https://redirect.github.com/gofrs/uuid) |
`v5.2.0` -> `v5.3.0` |
[![age](https://developer.mend.io/api/mc/badges/age/go/github.com%2fgofrs%2fuuid%2fv5/v5.3.0?slim=true)](https://docs.renovatebot.com/merge-confidence/)
|
[![adoption](https://developer.mend.io/api/mc/badges/adoption/go/github.com%2fgofrs%2fuuid%2fv5/v5.3.0?slim=true)](https://docs.renovatebot.com/merge-confidence/)
|
[![passing](https://developer.mend.io/api/mc/badges/compatibility/go/github.com%2fgofrs%2fuuid%2fv5/v5.2.0/v5.3.0?slim=true)](https://docs.renovatebot.com/merge-confidence/)
|
[![confidence](https://developer.mend.io/api/mc/badges/confidence/go/github.com%2fgofrs%2fuuid%2fv5/v5.2.0/v5.3.0?slim=true)](https://docs.renovatebot.com/merge-confidence/)
|

---

### Release Notes

<details>
<summary>gofrs/uuid (github.com/gofrs/uuid/v5)</summary>

###
[`v5.3.0`](https://redirect.github.com/gofrs/uuid/releases/tag/v5.3.0)

[Compare
Source](https://redirect.github.com/gofrs/uuid/compare/v5.2.0...v5.3.0)

#### Summary

In this release, we updated the package to participate in OpenSSF
Scorecard and tuned several development workflows and added some fuzz
tests. Additionally, We added `AtTime` generators for V1, V6, and V7 so
that users may generate UUIDs from time stamps.

**NOTE** Technically, the additional of the `AtTime` generators is a
breaking change to the `Generator` interface. We decided to go with a
`minor` update because of the unlikelihood of this interface being
implemented by a consumer, and to reduce the impact of releasing a major
version for this feature.
 

#### What's Changed

- Add "AtTime" generators for V1, V6, and V7 by
[@&#8203;kohenkatz](https://redirect.github.com/kohenkatz) in
[https://github.com/gofrs/uuid/pull/142](https://redirect.github.com/gofrs/uuid/pull/142)
- Fix typo in URL in README by
[@&#8203;kohenkatz](https://redirect.github.com/kohenkatz) in
[https://github.com/gofrs/uuid/pull/141](https://redirect.github.com/gofrs/uuid/pull/141)
- Add OpenSSF Best Practices Badge to README by
[@&#8203;cameracker](https://redirect.github.com/cameracker) in
[https://github.com/gofrs/uuid/pull/144](https://redirect.github.com/gofrs/uuid/pull/144)
- Create SECURITY.md by
[@&#8203;cameracker](https://redirect.github.com/cameracker) in
[https://github.com/gofrs/uuid/pull/143](https://redirect.github.com/gofrs/uuid/pull/143)
- Add OpenSSF Scorecard badge to readme by
[@&#8203;cameracker](https://redirect.github.com/cameracker) in
[https://github.com/gofrs/uuid/pull/149](https://redirect.github.com/gofrs/uuid/pull/149)
- Update fuzz tests to use go fuzz features by
[@&#8203;cameracker](https://redirect.github.com/cameracker) in
[https://github.com/gofrs/uuid/pull/148](https://redirect.github.com/gofrs/uuid/pull/148)

#### New Contributors

- [@&#8203;ldez](https://redirect.github.com/ldez) made their first
contribution in
[https://github.com/gofrs/uuid/pull/168](https://redirect.github.com/gofrs/uuid/pull/168)

**Full Changelog**:
gofrs/uuid@v5.2.0...v5.3.0

</details>

---

### Configuration

📅 **Schedule**: Branch creation - "before 6am on Monday" in timezone
Europe/Paris, Automerge - At any time (no schedule defined).

🚦 **Automerge**: Disabled by config. Please merge this manually once you
are satisfied.

♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the
rebase/retry checkbox.

🔕 **Ignore**: Close this PR and you won't be reminded about this update
again.

---

- [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check
this box

---

This PR was generated by [Mend Renovate](https://mend.io/renovate/).
View the [repository job
log](https://developer.mend.io/github/cozy/cozy-stack).

<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiIzOC43NC4xIiwidXBkYXRlZEluVmVyIjoiMzguNzQuMSIsInRhcmdldEJyYW5jaCI6Im1hc3RlciIsImxhYmVscyI6W119-->
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

Successfully merging this pull request may close these issues.

3 participants