Download the PHP package uma/uuid without Composer
On this page you can find all versions of the php package uma/uuid. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.
Informations about the package uuid
uuid
A SOLID and lightweight implementation of the UUID spec for PHP +8.2
Installation
Generators
RFC 4122 Version 1
How is the 'clockSeq' param chosen?
A fresh, random 14-bit value is generated every time that the
generate()
method is called on a Version1Generator instance.
This behaviour is compliant with the RFC spec (see section 4.1.5).
RFC 4122 Version 4
RFC 4122 Version 5
COMB Generator
This generator is not part of the RFC 4122 spec. It is a variant of the version 4 UUID that was first described (AFAIK) by Jimmy Nilsson in 2002 on an article named The Cost of GUIDs as Primary Keys.
COMB UUIDs are just version 4 UUIDs whose 48 higher bits have been overwritten with a timestamp. This guarantees to a certain extent that the generated values are monotonic (ever increasing), which is a most desired property when such values are used as database primary keys (or simply indexed).
What is the optional $granularity argument from the constructor?
The granularity reflects the precision of the timestamp that will be
stamped onto the UUIDs, and is in fact the number of fractional digits
that will be used from a call to microtime(true)
.
This number can go from 0 (which means second-precision) to 6 (which means microsecond-precision, the maximum that PHP is capable of and also the default value).
Since multiple COMB UUIDs generated with the same timestamp are not guaranteed to
be monotonic, the higher the granularity the stronger is that guarantee and the better
is the output of the CombGenerator
. To bring in some perspective, my laptop
can generate over 100k COMB UUIDs in the same second, but only 1 or 2 in the same microsecond.
What will happen when the higher 48 bits reach ffffffff-ffff
?
The generator will overflow and start again from 10000000-0000
. Of course, that means
that at this point the monotonic property of the generator will be lost!
When will the overflow occur?
It depends on the granularity that you have chosen, but the getOverflowDate()
method returns
the exact moment it will occur.
As I write this, the nearest overflow will occur on 2059-03-13 02:56:07 UTC (for a granularity of 5).
Sequential Generator (UNSAFE)
The SequentialGenerator
does not generate unique UUIDs at all. It can be used
as a replacement for real generators in testing contexts, where readable and
deterministic values might be desirable.
The first parameter of the generator will print a "pattern" on the higher 8 bytes of its UUIDs. The second is the offset at which the counting will begin. Both are optional.
The Uuid class
The Uuid
class is modeled as a value object that wraps valid UUID strings. It also has
named constructors to generate Uuid objects when their intended value is known beforehand.
Creating Uuid objects from strings
Uuid::fromString(string): Uuid
This is the preferred way to create new instances when you have an UUID value in a string variable. The method is case insensitive.
Uuid::fromBytes(string): Uuid
Creates a new Uuid instance from 16 raw bytes. This factory is extensively used by the generators but it can also cover some use cases of the end user of this library, such as when retrieving UUID strings in packed form from a database.
Uuid::nil(): Uuid
Convenience helper for generating instances of the NIL UUID.
Retrieving the inner value of an Uuid object
Uuid
objects have two getters: asString()
and asBytes()
. The former returns the UUID
in its canonical textual format, the latter as a raw sequence of 16 bytes.
They can also be casted to string. This is equivalent to calling the asString()
method.
FAQ
Which is the 'best' kind of UUID/Which one should I use?
UUIDs are often used as surrogate keys for tables in relational databases. This implies that they are indexed, and index performance depends in part on how continuous these values are. Hence, the 'best' kind of UUID is the COMB UUID.
I ran a benchmark on Postgres 9.6 in which I measured the time it took to insert a hundred million pregenerated UUIDs of different kinds. Version 4 UUIDs were inserted about 32 times slower into the table than a conventional autoincrementing integer. In contrast COMB UUIDs were "just" about 40% slower. These results are consistent with the ones reported 15 years ago by Mr. Nilsson in his own article.
In summary, you should use COMB UUIDs unless you have specific reasons to use another kind of UUID.
Where is Version3Generator?
Since it is exactly the same as Version 5 but relies on an even weaker hashing algorithm I do not see the point of adding it.
Where is Version2Generator?
As far as I know Version 2 UUIDs were never defined. The spec does not even mention them. Go figure.
Why does 1ma/uuid
specifically require a 64 bit build of PHP?
Because a few sections of the Version1Generator
and CombGenerator
code rely on integers
being 64 bit wide (in particular, the result of casting the output of microtime(true)
to an integer
may fill up to 56 bits at the time of writing).
If your PHP binary was built for a 32 bit architecture but don't intend to use neither of these time-based generators
you can still use this library, but will need to install it passing the --ignore-platform-reqs
flag to composer.
Can I write my own generators?
Yes, just implement the UuidGenerator
interface. Here's a sample
implementation that always returns the same Uuid. This one could be useful
in a unit testing context.
How do I run the tests?
How do I run the benchmarks?
As it is always the case in PHP, if the xdebug
extension is enabled it will
have a huge impact on runtime performance that will skew the results.