You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: components/uid.rst
+4-2Lines changed: 4 additions & 2 deletions
Original file line number
Diff line number
Diff line change
@@ -97,6 +97,8 @@ It's the same as UUIDv3 (explained above) but it uses ``sha1`` instead of
97
97
``md5`` to hash the given namespace and name (`read UUIDv5 spec <https://datatracker.ietf.org/doc/html/draft-ietf-uuidrev-rfc4122bis#name-uuid-version-5>`__).
98
98
This makes it more secure and less prone to hash collisions.
99
99
100
+
.. _uid-uuid-v6:
101
+
100
102
**UUID v6** (reordered time-based)
101
103
102
104
It rearranges the time-based fields of the UUIDv1 to make it lexicographically
@@ -364,8 +366,8 @@ entity primary keys::
364
366
Using UUIDs as primary keys is usually not recommended for performance reasons:
365
367
indexes are slower and take more space (because UUIDs in binary format take
366
368
128 bits instead of 32/64 bits for auto-incremental integers) and the non-sequential
367
-
nature of UUIDs fragments indexes. :ref:`UUID v7<uid-uuid-v7>` is the only
368
-
variant that solves the fragmentation issue (but the index size issue remains).
369
+
nature of UUIDs fragments indexes. :ref:`UUID v6<uid-uuid-v6>` and :ref:`UUID v7 <uid-uuid-v7>`
370
+
are the only variants that solves the fragmentation issue (but the index size issue remains).
369
371
370
372
When using built-in Doctrine repository methods (e.g. ``findOneBy()``), Doctrine
371
373
knows how to convert these UUID types to build the SQL query
0 commit comments