create-prisma-php-app 1.0.0

package/vendor/ramsey/uuid/docs/database.rst

@@ -0,0 +1,260 @@
+.. _database:
+
+===================
+Using In a Database
+===================
+
+.. tip::
+
+    `ramsey/uuid-doctrine`_ allows the use of ramsey/uuid as a `Doctrine field
+    type`_. If you use Doctrine, it's a great option for working with UUIDs and
+    databases.
+
+There are several strategies to consider when working with UUIDs in a database.
+Among these are whether to store the string representation or bytes and whether
+the UUID column should be treated as a primary key. We'll discuss a few of these
+approaches here, but the final decision on how to use UUIDs in a database is up
+to you since your needs will be different from those of others.
+
+.. note::
+
+    All database code examples in this section assume the use of `MariaDB`_ and
+    `PHP Data Objects (PDO)`_. If using a different database engine or
+    connection library, your code will differ, but the general concepts should
+    remain the same.
+
+
+.. _database.string:
+
+Storing As a String
+###################
+
+Perhaps the easiest way to store a UUID to a database is to create a ``char(36)``
+column and store the UUID as a string. When stored as a string, UUIDs require
+no special treatment in SQL statements or when displaying them.
+
+The primary drawback is the size. At 36 characters, UUIDs can take up a lot of
+space, and when handling a lot of data, this can add up.
+
+.. code-block:: sql
+    :caption: Create a table with a column for UUIDs
+    :name: database.uuid-column-example
+
+    CREATE TABLE `notes` (
+        `uuid` char(36) NOT NULL,
+        `notes` text NOT NULL
+    ) ENGINE=InnoDB DEFAULT CHARSET=utf8;
+
+Using this database table, we can store the string UUID using code similar to
+this (assume some of the variables in this example have been set beforehand):
+
+.. code-block:: php
+    :caption: Store a string UUID to the uuid column
+    :name: database.uuid-column-store-example
+
+    use Ramsey\Uuid\Uuid;
+
+    $uuid = Uuid::uuid4();
+
+    $dbh = new PDO($dsn, $username, $password);
+
+    $sth = $dbh->prepare('
+        INSERT INTO notes (
+            uuid,
+            notes
+        ) VALUES (
+            :uuid,
+            :notes
+        )
+    ');
+
+    $sth->execute([
+        ':uuid' => $uuid->toString(),
+        ':notes' => $notes,
+    ]);
+
+
+.. _database.bytes:
+
+Storing As Bytes
+################
+
+In :ref:`the previous example <database.uuid-column-store-example>`, we saw how
+to store the string representation of a UUID to a ``char(36)`` column. As
+discussed, the primary drawback is the size. However, if we store the UUID in
+byte form, we only need a ``char(16)`` column, saving over half the space.
+
+The primary drawback with this approach is ease-of-use. Since the UUID bytes are
+stored in the database, querying and selecting data becomes more difficult.
+
+.. code-block:: sql
+    :caption: Create a table with a column for UUID bytes
+    :name: database.uuid-bytes-example
+
+    CREATE TABLE `notes` (
+        `uuid` char(16) NOT NULL,
+        `notes` text NOT NULL
+    ) ENGINE=InnoDB DEFAULT CHARSET=utf8;
+
+Using this database table, we can store the UUID bytes using code similar to
+this (again, assume some of the variables in this example have been set
+beforehand):
+
+.. code-block:: php
+    :caption: Store UUID bytes to the uuid column
+    :name: database.uuid-bytes-store-example
+
+    $sth->execute([
+        ':uuid' => $uuid->getBytes(),
+        ':notes' => $notes,
+    ]);
+
+Now, when we ``SELECT`` the records from the database, we will need to convert
+the ``notes.uuid`` column to a ramsey/uuid object, so that we are able to use
+it.
+
+.. code-block:: php
+    :caption: Covert database UUID bytes to UuidInterface instance
+    :name: database.uuid-bytes-convert-example
+
+    use Ramsey\Uuid\Uuid;
+
+    $uuid = Uuid::uuid4();
+
+    $dbh = new PDO($dsn, $username, $password);
+
+    $sth = $dbh->prepare('SELECT uuid, notes FROM notes');
+    $sth->execute();
+
+    foreach ($sth->fetchAll() as $record) {
+        $uuid = Uuid::fromBytes($record['uuid']);
+
+        printf(
+            "UUID: %s\nNotes: %s\n\n",
+            $uuid->toString(),
+            $record['notes']
+        );
+    }
+
+We'll also need to query the database using the bytes.
+
+.. code-block:: php
+    :caption: Look-up the record from the database, using the UUID bytes
+    :name: database.uuid-bytes-select-example
+
+    use Ramsey\Uuid\Uuid;
+
+    $uuid = Uuid::fromString('278198d3-fa96-4833-abab-82f9e67f4712');
+
+    $dbh = new PDO($dsn, $username, $password);
+
+    $sth = $dbh->prepare('
+        SELECT uuid, notes
+        FROM notes
+        WHERE uuid = :uuid
+    ');
+
+    $sth->execute([
+        ':uuid' => $uuid->getBytes(),
+    ]);
+
+    $record = $sth->fetch();
+
+    if ($record) {
+        $uuid = Uuid::fromBytes($record['uuid']);
+
+        printf(
+            "UUID: %s\nNotes: %s\n\n",
+            $uuid->toString(),
+            $record['notes']
+        );
+    }
+
+
+.. _database.pk:
+
+Using As a Primary Key
+######################
+
+In the previous examples, we didn't use the UUID as a primary key, but it's
+logical to use the ``notes.uuid`` field as a primary key. There's nothing wrong
+with this approach, but there are a couple of points to consider:
+
+* InnoDB stores data in the primary key order
+* All the secondary keys also contain the primary key (in InnoDB)
+
+We'll deal with the first point in the section, :ref:`database.order`. For the
+second point, if you are using the string version of the UUID (i.e.,
+``char(36)``), then not only will the primary key be large and take up a lot of
+space, but every secondary key that uses that primary key will also be much
+larger.
+
+For this reason, if you choose to use UUIDs as primary keys, it might be worth
+the drawbacks to use UUID bytes (i.e., ``char(16)``) instead of the string
+representation (see :ref:`database.bytes`).
+
+.. hint::
+
+    If not using InnoDB with MySQL or MariaDB, consult your database engine
+    documentation to find whether it also has similar properties that will
+    factor into your use of UUIDs.
+
+
+.. _database.uk:
+
+Using As a Unique Key
+#####################
+
+Instead of :ref:`using UUIDs as a primary key <database.pk>`, you may choose to
+use an ``AUTO_INCREMENT`` column with the ``int unsigned`` data type as a
+primary key, while using a ``char(36)`` for UUIDs and setting a ``UNIQUE KEY``
+on this column. This will aid in lookups while helping keep your secondary keys
+small.
+
+.. code-block:: sql
+    :caption: Use an auto-incrementing column as primary key, with UUID as a unique key
+    :name: database.id-auto-increment-uuid-unique-key
+
+    CREATE TABLE `notes` (
+        `id` int(11) unsigned NOT NULL AUTO_INCREMENT,
+        `uuid` char(36) NOT NULL,
+        `notes` text NOT NULL,
+        PRIMARY KEY (`id`),
+        UNIQUE KEY `notes_uuid_uk` (`uuid`)
+    ) ENGINE=InnoDB DEFAULT CHARSET=utf8;
+
+
+.. _database.order:
+
+Insertion Order and Sorting
+###########################
+
+UUID versions 1, 2, 3, 4, and 5 are not *monotonically increasing*. If using
+these versions as primary keys, the inserts will be random, and the data will be
+scattered on disk (for InnoDB). Over time, as the database size grows, lookups
+will become slower and slower.
+
+.. tip::
+
+    See Percona's "`Storing UUID Values in MySQL`_" post, for more details on
+    the performance of UUIDs as primary keys.
+
+To minimize these problems, two solutions have been devised:
+
+1. :ref:`rfc4122.version6` UUIDs
+2. :ref:`rfc4122.version7` UUIDs
+
+.. note::
+
+    We previously recommended the use of the :ref:`timestamp-first COMB
+    <customize.timestamp-first-comb-codec>` or :ref:`ordered-time
+    <customize.ordered-time-codec>` codecs to solve these problems. However,
+    UUID versions 6 and 7 were defined to provide these solutions in a
+    standardized way.
+
+
+.. _ramsey/uuid-doctrine: https://github.com/ramsey/uuid-doctrine
+.. _Doctrine field type: https://www.doctrine-project.org/projects/doctrine-dbal/en/2.10/reference/types.html
+.. _MariaDB: https://mariadb.org
+.. _PHP Data Objects (PDO): https://www.php.net/pdo
+.. _Storing UUID Values in MySQL: https://www.percona.com/blog/2014/12/19/store-uuid-optimized-way/

package/vendor/ramsey/uuid/docs/faq.rst

@@ -0,0 +1,132 @@
+.. _faq:
+
+=================================
+Frequently Asked Questions (FAQs)
+=================================
+
+.. contents::
+    :local:
+    :depth: 1
+
+
+.. _faq.rhumsaa-abandoned:
+
+How do I fix "rhumsaa/uuid is abandoned" messages?
+##################################################
+
+When installing your project's dependencies using Composer, you might see the
+following message:
+
+.. code-block:: text
+
+    Package rhumsaa/uuid is abandoned; you should avoid using it. Use
+    ramsey/uuid instead.
+
+Don't panic. Simply execute the following commands with Composer:
+
+.. code-block:: bash
+
+    composer remove rhumsaa/uuid
+    composer require ramsey/uuid=^2.9
+
+After doing so, you will have the latest ramsey/uuid package in the 2.x series,
+and there will be no need to modify any code; the namespace in the 2.x series is
+still ``Rhumsaa``.
+
+
+.. _faq.final:
+
+Why does ramsey/uuid use ``final``?
+###################################
+
+You might notice that many of the concrete classes returned in ramsey/uuid are
+marked as ``final``. There are specific reasons for this choice, and I will
+offer a few solutions for those looking to extend or mock the classes for
+testing purposes.
+
+But Why?
+--------
+
+.. raw:: html
+
+    <div style="width:100%;height:0;padding-bottom:56%;position:relative;">
+        <iframe src="https://giphy.com/embed/eauCbbW6MvqKI" width="100%" height="100%" style="position:absolute" frameBorder="0" class="giphy-embed" allowFullScreen></iframe>
+    </div>
+    <p><a href="https://giphy.com/gifs/eauCbbW6MvqKI">via GIPHY</a></p>
+
+First, let's take a look at why ramsey/uuid uses ``final``.
+
+UUIDs are defined by a set of rules --- published as `RFC 4122`_ --- and those
+rules shouldn't change. If they do, then it's no longer a UUID --- at least not
+as defined by `RFC 4122`_.
+
+As an example, let's think about :php:class:`Rfc4122\\UuidV1
+<Ramsey\\Uuid\\Rfc4122\\UuidV1>`. If our application wants to do something
+special with this type, it might use the ``instanceof`` operator to check that a
+variable is a UuidV1, or it might use a type hint on a method argument. If a
+third-party library passes a UUID object to us that extends UuidV1 but
+overrides some very important internal logic, then we may no longer have a
+version 1 UUID. Perhaps we can all be adults and play nicely, but ramsey/uuid
+cannot make any guarantees for any subclasses of UuidV1.
+
+However, ramsey/uuid *can* make guarantees about classes that implement
+:php:interface:`UuidInterface <Ramsey\\Uuid\\UuidInterface>` or
+:php:interface:`Rfc4122\\UuidInterface <Ramsey\\Uuid\\Rfc4122\\UuidInterface>`.
+
+So, if we're working with an instance of a class that is marked ``final``, we
+can guarantee that the rules for the creation of that object will not change,
+even if a third-party library passes us an instance of the same class.
+
+This is the reason why ramsey/uuid specifies certain :ref:`argument and return
+types <reference.types>` that are marked ``final``. Since these are ``final``,
+ramsey/uuid is able to guarantee the type of data these value objects contain.
+:php:class:`Type\\Integer <Ramsey\\Uuid\\Type\\Integer>` should never contain
+any characters other than numeral digits, and :php:class:`Type\\Hexadecimal
+<Ramsey\\Uuid\\Type\\Hexadecimal>` should never contain any characters other
+than hexadecimal digits. If other libraries could extend these and return them
+from UUID instances, then ramsey/uuid cannot guarantee their values.
+
+This is very similar to using strict types with ``int``, ``float``, or ``bool``.
+These types cannot change, so think of final classes in ramsey/uuid as types
+that cannot change.
+
+Overriding Behavior
+-------------------
+
+You may override the behavior of ramsey/uuid as much as you want. Despite the
+use of ``final``, the library is very flexible. Take a look at the myriad
+opportunities to change how the library works:
+
+* :ref:`rfc4122.version1.random`
+* :ref:`customize.timestamp-first-comb-codec`
+* :ref:`customize.factory`
+* :ref:`And more... <customize>`
+
+ramsey/uuid is able to provide this flexibility through the use of `interfaces`_,
+`factories`_, and `dependency injection`_.
+
+At the same time, ramsey/uuid is able to guarantee that neither a
+:php:class:`UuidV1 <Ramsey\\Uuid\\Rfc4122\\UuidV1>` nor a
+:php:class:`UuidV4 <Ramsey\\Uuid\\Rfc4122\\UuidV4>` nor an
+:php:class:`Integer <Ramsey\\Uuid\\Type\\Integer>` nor a
+:php:class:`Time <Ramsey\\Uuid\\Type\\Time>`, etc. will ever change because of
+`downstream`_ code.
+
+UUIDs have specific rules that make them practically unique. ramsey/uuid ensures
+that other code cannot change this expectation while allowing your code and
+third-party libraries to change how UUIDs are generated and to return different
+types of UUIDs not specified by `RFC 4122`_.
+
+Testing With UUIDs
+------------------
+
+Sometimes, the use of ``final`` can throw a wrench in our ability to write
+tests, but it doesn't have to be that way. To learn a few techniques for using
+ramsey/uuid instances in your tests, take a look at :ref:`testing`.
+
+
+.. _RFC 4122: https://tools.ietf.org/html/rfc4122
+.. _interfaces: https://www.php.net/interfaces
+.. _factories: https://en.wikipedia.org/wiki/Factory_%28object-oriented_programming%29
+.. _dependency injection: https://en.wikipedia.org/wiki/Dependency_injection
+.. _downstream: https://en.wikipedia.org/wiki/Downstream_(software_development)

package/vendor/ramsey/uuid/docs/index.rst

@@ -0,0 +1,51 @@
+.. _index:
+
+==================
+ramsey/uuid Manual
+==================
+
+For `ramsey/uuid <https://github.com/ramsey/uuid>`_ |version|. Updated on |today|.
+
+This work is licensed under the `Creative Commons Attribution 4.0 International
+<https://creativecommons.org/licenses/by/4.0/>`_ license.
+
+.. admonition:: Support ramsey/uuid!
+    :class: tip
+
+    Your support encourages and motivates me to continue building and
+    maintaining open source software. If you benefit from my work, consider
+    supporting me financially.
+
+    You may support ramsey/uuid as an individual through `GitHub Sponsors
+    <https://github.com/sponsors/ramsey>`_ or as a company through the
+    **Tidelift Subscription**. With the Tidelift Subscription, you can get
+    commercial maintenance and assurances, while supporting my work.
+
+    Learn more about :ref:`ramsey/uuid for enterprise <tidelift>`!
+
+Contents
+--------
+
+.. toctree::
+    :maxdepth: 2
+    :includehidden:
+
+    introduction
+    quickstart
+    rfc4122
+    nonstandard
+    database
+    customize
+    testing
+    upgrading
+    FAQs <faq>
+    reference
+    copyright
+    tidelift
+
+
+Indices and Tables
+------------------
+
+* :ref:`genindex`
+* :ref:`search`

package/vendor/ramsey/uuid/docs/introduction.rst

@@ -0,0 +1,31 @@
+.. _introduction:
+
+============
+Introduction
+============
+
+ramsey/uuid is a PHP library for generating and working with `RFC 4122`_ version
+1, 2, 3, 4, 5, 6, and 7 universally unique identifiers (UUID). ramsey/uuid also
+supports optional and non-standard features, such as GUIDs and other approaches
+for encoding/decoding UUIDs.
+
+What Is a UUID?
+###############
+
+A universally unique identifier, or UUID, is a 128-bit unsigned integer, usually
+represented as a hexadecimal string split into five groups with dashes. The most
+widely-known and used types of UUIDs are defined by `RFC 4122`_.
+
+A UUID, when encoded in hexadecimal string format, looks like:
+
+.. code-block:: text
+
+    ebb5c735-0308-4e3c-9aea-8a270aebfe15
+
+The probability of duplicating a UUID is close to zero, so they are a great
+choice for generating unique identifiers in distributed systems.
+
+UUIDs can also be stored in binary format, as a string of 16 bytes.
+
+
+.. _RFC 4122: https://tools.ietf.org/html/rfc4122

package/vendor/ramsey/uuid/docs/nonstandard/guid.rst

@@ -0,0 +1,152 @@
+.. _nonstandard.guid:
+
+===================================
+Globally Unique Identifiers (GUIDs)
+===================================
+
+.. tip::
+
+    Using these techniques to work with GUIDs is useful if you're working with
+    identifiers that have been stored in GUID byte order. For example, this is
+    the case if working with the ``UNIQUEIDENTIFIER`` data type in Microsoft SQL
+    Server. This is a GUID, stored as a 16-byte binary string. If working
+    directly with the bytes, you may use the GUID functionality in ramsey/uuid
+    to properly handle this data type.
+
+According to the Windows Dev Center article on `GUID structure`_, "GUIDs are the
+Microsoft implementation of the distributed computing environment (DCE)
+universally unique identifier." For all intents and purposes, a GUID string
+representation is identical to that of an `RFC 4122`_ UUID. For historical
+reasons, *the byte order is not*.
+
+The `.NET Framework documentation`_ explains:
+
+    Note that the order of bytes in the returned byte array is different from
+    the string representation of a Guid value. The order of the beginning
+    four-byte group and the next two two-byte groups is reversed, whereas the
+    order of the last two-byte group and the closing six-byte group is the same.
+
+This is best explained by example.
+
+.. code-block:: php
+    :caption: Decoding a GUID from byte representation
+    :name: nonstandard.guid.decode-bytes-example
+
+    use Ramsey\Uuid\FeatureSet;
+    use Ramsey\Uuid\UuidFactory;
+
+    // The bytes of a GUID previously stored in some datastore.
+    $guidBytes = hex2bin('0eab93fc9ec9584b975e9c5e68c53624');
+
+    $useGuids = true;
+    $featureSet = new FeatureSet($useGuids);
+    $factory = new UuidFactory($featureSet);
+
+    $guid = $factory->fromBytes($guidBytes);
+
+    printf(
+        "Class: %s\nGUID: %s\nVersion: %d\nBytes: %s\n",
+        get_class($guid),
+        $guid->toString(),
+        $guid->getFields()->getVersion()?->value,
+        bin2hex($guid->getBytes())
+    );
+
+This transforms the bytes of a GUID, as represented by ``$guidBytes``, into a
+:php:class:`Ramsey\\Uuid\\Guid\\Guid` instance and prints out some details about
+it. It looks something like this:
+
+.. code-block:: text
+
+    Class: Ramsey\Uuid\Guid\Guid
+    GUID: fc93ab0e-c99e-4b58-975e-9c5e68c53624
+    Version: 4
+    Bytes: 0eab93fc9ec9584b975e9c5e68c53624
+
+Note the difference between the string GUID and the bytes. The bytes are
+arranged like this:
+
+.. code-block:: text
+
+    0e ab 93 fc 9e c9 58 4b 97 5e 9c 5e 68 c5 36 24
+
+In an `RFC 4122`_ UUID, the bytes are stored in the same order as you see
+presented in the string representation. This is often called *network byte
+order*, or *big-endian* order. In a GUID, the order of the bytes are reversed
+in each grouping for the first 64 bits and stored in *little-endian* order. The
+remaining 64 bits are stored in network byte order. See `Endianness
+<#nonstandard-guid-endianness>`_ to learn more.
+
+.. caution::
+
+    The bytes themselves do not indicate their order. If you decode GUID bytes
+    as a UUID or UUID bytes as a GUID, you will get the wrong values. However,
+    you can always create a GUID or UUID from the same string value; the bytes
+    for each will be in a different order, even though the string is the same.
+
+    The key is to know ahead of time in what order the bytes are stored. Then,
+    you will be able to decode them using the correct approach.
+
+
+Converting GUIDs to UUIDs
+#########################
+
+Continuing from the example, :ref:`nonstandard.guid.decode-bytes-example`, we
+can take the GUID string representation and convert it into a standard UUID.
+
+.. code-block:: php
+    :caption: Convert a GUID to a UUID
+    :name: nonstandard.guid.convert-example
+
+    $uuid = Uuid::fromString($guid->toString());
+
+    printf(
+        "Class: %s\nUUID: %s\nVersion: %d\nBytes: %s\n",
+        get_class($uuid),
+        $uuid->toString(),
+        $uuid->getFields()->getVersion()?->value,
+        bin2hex($uuid->getBytes())
+    );
+
+Because the GUID was a version 4, random UUID, this creates an instance of
+:php:class:`Ramsey\\Uuid\\Rfc4122\\UuidV4` from the GUID string and prints out a
+few details about it. It looks something like this:
+
+.. code-block:: text
+
+    Class: Ramsey\Uuid\Rfc4122\UuidV4
+    UUID: fc93ab0e-c99e-4b58-975e-9c5e68c53624
+    Version: 4
+    Bytes: fc93ab0ec99e4b58975e9c5e68c53624
+
+Note how the UUID string is identical to the GUID string. However, the byte
+order is different, since they are in big-endian order. The bytes are now
+arranged like this:
+
+.. code-block:: text
+
+    fc 93 ab 0e c9 9e 4b 58 97 5e 9c 5e 68 c5 36 24
+
+
+.. admonition:: Endianness
+    :name: nonstandard.guid.endianness
+
+    Big-endian and little-endian refer to the ordering of bytes in a multi-byte
+    number. Big-endian order places the most significant byte first, followed by
+    the other bytes in descending order. Little-endian order places the least
+    significant byte first, followed by the other bytes in ascending order.
+
+    Take the hexadecimal number ``0x1234``, for example. In big-endian order,
+    the bytes are stored as ``12 34``, and in little-endian order, they are
+    stored as ``34 12``. In either case, the number is still ``0x1234``.
+
+    Networking protocols usually use big-endian ordering, while computer
+    processor architectures often use little-endian ordering.
+    The terms originated in Jonathan Swift's *Gulliver's Travels*, where the
+    Lilliputians argue over which end of a hard-boiled egg is the best end to
+    crack.
+
+
+.. _GUID structure: https://docs.microsoft.com/en-us/windows/win32/api/guiddef/ns-guiddef-guid#remarks
+.. _RFC 4122: https://tools.ietf.org/html/rfc4122
+.. _.NET Framework documentation: https://docs.microsoft.com/en-us/dotnet/api/system.guid.tobytearray#remarks

package/vendor/ramsey/uuid/docs/nonstandard/other.rst

@@ -0,0 +1,49 @@
+.. _nonstandard.other:
+
+=======================
+Other Nonstandard UUIDs
+=======================
+
+Sometimes, you might encounter a string that looks like a UUID but doesn't
+follow the `RFC 4122`_ specification. Take this string, for example:
+
+.. code-block:: text
+
+    d95959bc-2ff5-43eb-fccd-14883ba8f174
+
+At a glance, this looks like a valid UUID, but the variant bits don't match RFC
+4122. Instead of throwing a validation exception, ramsey/uuid will assume this
+is a UUID, since it fits the format and has 128 bits, but it will represent it
+as a :php:class:`Ramsey\\Uuid\\Nonstandard\\Uuid`.
+
+.. code-block:: php
+    :caption: Create an instance of Nonstandard\\Uuid from a non-RFC 4122 UUID
+
+    use Ramsey\Uuid\Uuid;
+
+    $uuid = Uuid::fromString('d95959bc-2ff5-43eb-fccd-14883ba8f174');
+
+    printf(
+        "Class: %s\nUUID: %s\nVersion: %d\nVariant: %s\n",
+        get_class($uuid),
+        $uuid->toString(),
+        $uuid->getFields()->getVersion()?->value,
+        $uuid->getFields()->getVariant()?->value
+    );
+
+This will create a Nonstandard\\Uuid from the given string and print out a few
+details about it. It will look something like this:
+
+.. code-block:: text
+
+    Class: Ramsey\Uuid\Nonstandard\Uuid
+    UUID: d95959bc-2ff5-43eb-fccd-14883ba8f174
+    Version: 0
+    Variant: 7
+
+Note that the version is 0. Since the variant is 7, and there is no
+formal specification for this variant of UUID, ramsey/uuid has no way of knowing
+what type of UUID this is.
+
+
+.. _RFC 4122: https://tools.ietf.org/html/rfc4122

package/vendor/ramsey/uuid/docs/nonstandard/version6.rst

@@ -0,0 +1,17 @@
+.. _nonstandard.version6:
+
+=========================
+Version 6: Reordered Time
+=========================
+
+.. attention::
+
+    This documentation has moved to :ref:`RFC 4122 UUIDs: Version 6: Reordered
+    Time <rfc4122.version6>`.
+
+    Version 6 UUIDs have been promoted to the ``Rfc4122`` namespace. While still
+    in draft form, the version 6 format is not expected to change in any way
+    that breaks compatibility.
+
+    The :php:class:`Ramsey\\Uuid\\Nonstandard\\UuidV6` class is deprecated in
+    favor of :php:class:`Ramsey\\Uuid\\Rfc4122\\UuidV6`.