nickva commented on code in PR #5699:
URL: https://github.com/apache/couchdb/pull/5699#discussion_r2427347719


##########
src/couch/src/couch_uuids.erl:
##########
@@ -122,37 +126,35 @@ inc() ->
     rand:uniform(16#ffd).
 
 state() ->
-    AlgoStr = config:get("uuids", "algorithm", "sequential"),
+    AlgoStr = config_algorithm(),
     case couch_util:to_existing_atom(AlgoStr) of
         random ->
             random;
         utc_random ->
-            ClockSeq = micros_since_epoch(os:timestamp()),
+            ClockSeq = micros_since_epoch(),
             {utc_random, ClockSeq};
         utc_id ->
-            ClockSeq = micros_since_epoch(os:timestamp()),
+            ClockSeq = micros_since_epoch(),
             UtcIdSuffix = config:get("uuids", "utc_id_suffix", ""),
             {utc_id, UtcIdSuffix, ClockSeq};
         sequential ->
             {sequential, new_prefix(), inc()};
         uuid_v7 ->
             uuid_v7;
+        uuid_v7_hex ->

Review Comment:
   If we're going with changing the default I think its shape should be 
consistent with previous algorithm to be least disruptive. 
   
   Also the RFC specifically mentions databases 
https://datatracker.ietf.org/doc/rfc9562/ :
   
   ```
   6.13.  DBMS and Database Considerations
   
      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.
   ```
   
   We can't transmit binaries in JSON so we use what we already do for these 
IDs -- we hex-encode them. I can see having `uuid_v7_base32` or something in 
the future and that will certainly not have any dashes in it.
   
   > I don't see a reason to provide two formats for essentially the same 
thing, so I think it has to come to a dev@ vote to get a decision.
   
   Well the fact that we can't agree exactly on it, probably indicate it's not 
bad idea to have both?



-- 
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