public final class UUIDs extends Object
"com.datastax.driver.PID"is set then the value to use as a PID will be read from that property;
getpid()is possible, then the PID will be read from that call;
RuntimeMXBean, which is a well-known, yet undocumented "hack", since most JVMs tend to use the JVM's PID as part of that MXBean name;
|Modifier and Type||Field and Description|
The System property to use to force the value of the process ID (PID).
|Modifier and Type||Method and Description|
Creates a "fake" time-based UUID that sorts as the biggest possible version 1 UUID generated at the provided timestamp.
Creates a new random (version 4) UUID.
Creates a "fake" time-based UUID that sorts as the smallest possible version 1 UUID generated at the provided timestamp.
Creates a new time-based (version 1) UUID.
Return the Unix timestamp contained by the provided time-based UUID.
public static UUID random()
This method is just a convenience for
public static UUID timeBased()
UUIDs generated by this method are suitable for use with the
type. In particular the generated UUID includes the timestamp of its generation.
Note that there is no way to provide your own timestamp. This is deliberate, as we feel that this does not conform to the UUID specification, and therefore don't want to encourage it through the API. If you want to do it anyway, use the following workaround:
Random random = new Random(); UUID uuid = new UUID(UUIDs.startOf(userProvidedTimestamp).getMostSignificantBits(), random.nextLong());If you simply need to perform a range query on a
timeuuidcolumn, use the "fake" UUID generated by
public static UUID startOf(long timestamp)
Such created UUIDs are useful in queries to select a time range of a
The UUIDs created by this method are not unique and as such are not suitable
for anything else than querying a specific time range. In particular, you should not insert
such UUIDs. "True" UUIDs from user-provided timestamps are not supported (see
timeBased() for more explanations).
Also, the timestamp to provide as a parameter must be a Unix timestamp (as returned by
Date.getTime()), and not a count
of 100-nanosecond intervals since 00:00:00.00, 15 October 1582 (as required by RFC-4122).
In other words, given a UUID
uuid, you should never call
startOf(uuid.timestamp()) but rather
Lastly, please note that Cassandra's
timeuuid sorting is not compatible with
UUID.compareTo(java.util.UUID) and hence the UUIDs created by this method are not necessarily lower bound for
that latter method.
timestamp- the Unix timestamp for which the created UUID must be a lower bound.
timeuuidsorting) UUID of
public static UUID endOf(long timestamp)
startOf(long) for explanations about the intended usage of such UUID.
timestamp- the Unix timestamp for which the created UUID must be an upper bound.
timeuuidsorting) UUID of
public static long unixTimestamp(UUID uuid)
This method is not equivalent to
UUID.timestamp(). More precisely, a version 1 UUID
stores a timestamp that represents the number of 100-nanoseconds intervals since midnight, 15
October 1582 and that is what
UUID.timestamp() returns. This method however converts
that timestamp to the equivalent Unix timestamp in milliseconds, i.e. a timestamp representing
a number of milliseconds since midnight, January 1, 1970 UTC. In particular, the timestamps
returned by this method are comparable to the timestamps returned by
uuid- the UUID to return the timestamp of.
uuidis not a version 1 UUID.
Copyright © 2012–2019. All rights reserved.