-
Notifications
You must be signed in to change notification settings - Fork 38
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
Remove Random instance for UUID, or mark it as deprecated #22
Comments
Are you worried because someone might try to use the instance with |
I'm worried about this kind of usage: silkapp/rest@e4ef6a6 . If you do this, you're going to get 64-bit UUIDs and you don't realize it. |
Note that my comment above is based on #15 (comment) . I think if the
I still think this difference in behavior warrants at the very least some documentation/warning, considering that UUIDs are very often used to implement things like user sessions tokens that rely on the UUIDs to be hard to predict. |
I ran into this, couldn't figure out how to use the I think it would be helpful to say that one should use |
@prikhi would you be interested in providing a PR enhancing the Haddock documentation to that effect? |
[#22] Document Difference Between randomIO & nextRandom
I think we're running into this in production, we're getting a lot of collisions of UUIDs generated from a bunch of Lambdas, so we're now looking at generating UUID using something like cryptonite instead. Edit: Looks like we're probably using the wrong way to generate UUIDs, and V4.nextRandom should be what we use. |
https://hackage.haskell.org/package/uuid-1.3.13/docs/Data-UUID-V4.html uses I'm tempted to remove ... but there aren't any reasons to make major release so for now |
See #15 (comment) for motivations, and entire ticket for context.
The text was updated successfully, but these errors were encountered: