Hi,
The function is defined here[1]. I hope my email client isn't
butchering the code.
public static final Function *nowFct *= new NativeScalarFunction("now",
TimeUUIDType.*instance*)
{
public ByteBuffer execute(ProtocolVersion protocolVersion,
List<ByteBuffer> parameters)
{
return ByteBuffer.*wrap*(UUIDGen.*getTimeUUIDBytes*());
}
};
It's documented as
http://cassandra.apache.org/doc/latest/cql/functions.html#timeuuid-functions:
> The now function takes no arguments and generates, on the coordinator
> node, a new unique timeuuid (at the time where the statement using it
> is executed).
> Now is the behavior consistent with the documentation? Well it depends
> on how you define statement (CQL statement, or function call) I
> suppose. I do think the doc needs to be updated because in terms of
> principle of least surprise yes this is a little surprising.
I know of a couple of systems that associate a timestamp with each
transaction and will always return the same time when you request the
current time. However you aren't requesting the current time you are
requesting a UUID using a function named now(). I think we are stuck
with the behavior and need an additional function that does what would
expect from a function named now().
As a work around you can pass the time in as a parameter and then you
can guarantee it will be the same in each position.
There is also the implicit
https://docs.datastax.com/en/cql/3.3/cql/cql_using/useWritetime.html for
each column. Writetime didn't seem have hits in the Apache docs so I
linked to the Datastax docs. I'll see about getting them updated.
Regards,
Ariel
On Tue, Nov 29, 2016, at 04:49 PM, Terry Liu wrote:
> It appears that a single query that calls Cassandra's `now()`
> time function may actually cause a query to write or return
> different times.
>
> Is this the expected or defined behavior, and if so, why does it
> behave like this rather than evaluating `now()` once across an entire
> statement?
>
> This really affects UPDATE statements but to test it more easily, you
> could try something like:
>
> SELECT toTimestamp(now()) as a, toTimestamp(now()) as b
> FROM keyspace.table
> LIMIT 100;
>
> If you run that a few times, you should eventually see that the
> timestamp returned moves onto the next millisecond mid-query.
>
> --
> *Software Engineer*
> Turnitin - http://www.turnitin.com[2]
> t...@turnitin.com
Links:
1.
https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/cql3/functions/TimeFcts.java#L54
2. http://www.turnitin.com/
