nickva commented on code in PR #5699:
URL: https://github.com/apache/couchdb/pull/5699#discussion_r2427537145
##########
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:
> I saw that section of the RFC but these UUID's will not be stored as
128-bit binary
We're storing uuids as binaries from this module internally in the purge id
and sequence trees. If we could store document IDs in a more compact way we
would. In fact, I created a base 36 encoding version to show how it can be
done. The same UUID v7 information can be encoded in only 24 bytes instead of
36. Having smaller, more compact IDs, which still have the same information
content in a database is worth-while I think, especially with how we handle
append-only B-trees, and keep re-writing the whole paths to the root on every
commit.
> that section does not apply to document id strings.
The intent behind the section is to indicate to database they they can use a
more compact representation instead of the nicely formatted strings. The
dashboards and user interfaces can use the nicely formatted strings but we
don't have to waste space in doc IDs repeating the same 4 extra dashes every
time.
--
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]
