nickva opened a new pull request, #5699:
URL: https://github.com/apache/couchdb/pull/5699

   The UUID v7 along with the `random` UUID types do not require going through 
the gen_server as they do not need to keep any state. This should make the 
system more robust and prevent clients from overwhelming the node with 
concurrent requests to the `/_uuid` endpoint.
   
   Add a plain hex-encoded version of UUID v7 as `uuid_v7_hex` and use that as 
the new default. The `hex` version is used according to the guidance in:
   
   https://datatracker.ietf.org/doc/rfc9562/
   
   ```
      For many applications, such as databases, storing UUIDs as text is
      unnecessarily verbose, requiring 288 bits to represent 128-bit UUID
      values.  Thus, where feasible, UUIDs SHOULD be stored within database
      applications as the underlying 128-bit binary value.
   ```
   
   Ideally we'd like to use just the 128 bit binary, however since we're 
transmitting json we'll encode it as base 16. This way its shape is also 
exactly compatible (same length and characters) with the previous `sequential` 
default.
   
   In the future more compact encodings may be added: base32, base58 etc.
   
   Users can still generate properly formatted UUID v7 strings (with dashes) by 
using the `uuid_v7` algorithm. That will produce 36 byte character strings 
which may look like:
   
   ```
       [
          "0199df37-5929-7032-b402-c3e61fbbf88f",
          "0199df37-5929-7851-9492-e566433ced7f",
          ...
       ]
   ```
   
   While at it, expand the test suite and add more coverage and also ensure to 
test the sizes of the returned values.
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to