Subject: [boost] [uuid] sequential_generator / comb_generator / utc_generator / timestamp_generator
From: Adam Walling (adam.walling_at_[hidden])
Date: 2014-03-05 19:08:37
For personal use, I've created a few generators that create sequential and
time-based uuids. However there does not seem to be a single standard for
these kinds of algorithms.
While tidying up this code, I've run into some obstacles with
generalization of the logic.
Although some applications like SQL Server will use GUIDs and
lexicographically compare based on the least significant bytes of Data4 for
boost::uuids' purposes we can simply assume a block of 16 bytes.
The generic approach is to combine (basic_comb_generator) a number of bytes
from a sequential source, filling the rest of the bytes with random data.
What concerns me is the choice of source and the number of bytes to use.
And additionally the value which specifies the variant / version.
The usual choices seem to be 8 or 6 bytes. The source is also usually UTC
Unix time. However the original uuid version used nanosecond intervals and
the MAC address.
Am I worrying too much about extensibility? As it is now my
basic_comb_generator has a template param for a source, a number of bytes
of the source to use, and a UniformRandomNumberGenerator to fill the rest.
Since resolution may be a second if using Unix time they may not be
consistently sequential but generally so, hence my hesitation to name the
generator typedef as sequential. Of course it is possible to use even
I suppose I am gauging interest in this feature, as well as asking if there
are any thoughts or suggestions on how others would likely use this, and
alternative or standard algorithms defined.
Once I have some feedback I intend to complete the code and bounce it back
on here for any further comments before lobbying to include anything within
the library. It seems like commonly needed functionality at least!
Nilsson article here for SQL Server:
CouchDB's uuid generation algorithms:
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk