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 final String PID_SYSTEM_PROPERTY
public static UUID random()
public static UUID timeBased()
timeuuidCassandra 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)
timeuuidcolumn. 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(unixTimestamp(uuid)). Lastly, please note that Cassandra's
timeuuidsorting 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)
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.