-
-
Notifications
You must be signed in to change notification settings - Fork 9.6k
[Uid] Add UidFactory to create Ulid and Uuid from timestamps and randomness/nodes #39507
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
Conversation
f0b803d
to
8745fcb
Compare
8745fcb
to
421431c
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure for ULID, but this is exactly what address UUID V5: $predectible = Uuid::v5('my entity', $id);
Choosing randomness does not make sense. It is not random anymore then. |
What about adding the $time and $node arg to
Thinking about this, we could merge the two arguments in one: passing a single UUID to the constructor is enough to derive both a node id for v1&6 and a namespace for v3&5, WDYT? About Ulid, I think we should remove the $randomness argument.
About this part, maybe leave it for a later PR. No need to do it unless one has the need for it. Also, I'm wondering, what about giving meaningful names to the factory methods?
|
27bffd6
to
e6ec19f
Compare
I pushed a new version taking into account the various comments. Tell me what you think. I prefer to split UidFactory and UlidFactory since the timestamp meaning is not the same. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, I like it. Here are some more comments.
What about adding the $time and $node arg to Uuid::v1()? That could be done in a separate smaller PR.
WDYT about this one? Should be easy thanks to the new generate()
methods, don't you think?
src/Symfony/Bundle/FrameworkBundle/DependencyInjection/Configuration.php
Outdated
Show resolved
Hide resolved
src/Symfony/Bundle/FrameworkBundle/DependencyInjection/Configuration.php
Outdated
Show resolved
Hide resolved
src/Symfony/Bundle/FrameworkBundle/DependencyInjection/Configuration.php
Outdated
Show resolved
Hide resolved
311c10b
to
c03a9c6
Compare
src/Symfony/Bundle/FrameworkBundle/DependencyInjection/Configuration.php
Outdated
Show resolved
Hide resolved
20d9e65
to
0df232a
Compare
Done :) I've replaced all |
ccd555c
to
86861d3
Compare
…s-grekas) This PR was merged into the 5.3-dev branch. Discussion ---------- [Uid] Add RFC4122 UUID namespaces as constants | Q | A | ------------- | --- | Branch? | 5.x | Bug fix? | no | New feature? | yes | Deprecations? | no | Tickets | - | License | MIT | Doc PR | - Discussed with @tgalopin Will play well with #39507 Commits ------- 4e73aeb [Uid] Add RFC4122 UUID namespaces as constants
…s-grekas) This PR was merged into the 5.3-dev branch. Discussion ---------- [DoctineBridge] Remove UuidV*Generator classes | Q | A | ------------- | --- | Branch? | 5.x | Bug fix? | no | New feature? | yes | Deprecations? | no | Tickets | - | License | MIT | Doc PR | - There is no benefit in using these classes over creating the UUIDs inline. Let's keep things simple. For `UlidGenerator`, I'm keeping it as it will provide something useful once #39507 and doctrine/DoctrineBundle#1284 are finished. Commits ------- 3c296bd [DoctineBridge] Remove UuidV*Generator
9d310d5
to
85f0300
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
After many iterations, I'm happy to say that this is ready.
src/Symfony/Bridge/Doctrine/Tests/IdGenerator/UlidGeneratorTest.php
Outdated
Show resolved
Hide resolved
src/Symfony/Bundle/FrameworkBundle/DependencyInjection/FrameworkExtension.php
Show resolved
Hide resolved
2c0aa47
to
04a0f93
Compare
04a0f93
to
88a99dd
Compare
Thank you @fancyweb. |
Ref #36097
When you migrate an existing resource identifier to an uid, you might want to choose the timestamp so that it is coherent with the creation date of the existing resource. (eg: I have a row in a table with id=1, created_at=2018-12-11 19:00:00, I would like to use that timestamp to create the resource Ulid).
It can also be useful to choose the time of the Ulid or the node of the Uuid.
This PR provides new services and corresponding autowiring aliases and implementations:
ulid.factory
<=>Symfony\Component\Uid\Factory\UlidFactory
uuid.factory
<=>Symfony\Component\Uid\Factory\UuidFactory
time_based_uuid.factory
<=>Symfony\Component\Uid\Factory\TimeBasedUuidFactory
random_based_uuid.factory
<=>Symfony\Component\Uid\Factory\RandomBasedUuidFactory
name_based_uuid.factory
<=>Symfony\Component\Uid\Factory\NameBasedUuidFactory
All factories have a
create()
method that returns a different kind ofAbstractUid
.UuidFactory::create()
returns either a time-based Uuid, or a random one. It defaults to a time-based UuidV6, because that's what is most favorable to DB indexes.This default is configurable using semantic config. E.g. this switches to UuidV4 by default:
Semantic configuration also allows configuring a default "node" for UuidV1/V6 and a default "namespace" for UuidV3/V5.
A
UuidGenerator
is also provided, that can be used to generate the "id" of entities. See also doctrine/DoctrineBundle#1284 for a sidekick PR.By using these factories instead of creating UUIDs/ULIDs inline, one will be able to centralize the definition of e.g. the UUID version that should be used for time/name-based UUIDs, or to define the same "node" per php-fpm instance, to easily identify the origin of all time-based UUIDs, while not leaking MAC info nor reducing the uniqueness.
And of course, these factories also allow easy mocking of their return values in tests.