You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Sylvain Lebresne (JIRA)" <ji...@apache.org> on 2014/01/20 02:53:21 UTC

[jira] [Commented] (CASSANDRA-6601) WRITETIME of a null value does not return a time

    [ https://issues.apache.org/jira/browse/CASSANDRA-6601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13876080#comment-13876080 ] 

Sylvain Lebresne commented on CASSANDRA-6601:
---------------------------------------------

bq. When a cell's value is null the CQL WRITETIME function returns null. I was expecting it to return a timestamp.

Not entirely sure why you would. A null in CQL means the absence of said column basically, so there is no timestamp to return and I don't see what else than null we could return. What you are seeing with the CLI is the row marker, but the timestamp of that is potentially unrelated to the column you're asking the timestamp with so ...

> WRITETIME of a null value does not return a time
> ------------------------------------------------
>
>                 Key: CASSANDRA-6601
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-6601
>             Project: Cassandra
>          Issue Type: Bug
>         Environment: Cassandra 2.0.2
>            Reporter: Theo Hultberg
>
> When a cell's value is {{null}} the CQL {{WRITETIME}} function returns null. I was expecting it to return a timestamp. Looking at the data in {{cassandra-cli}} I can see that the cell has a timestamp.
> Here's a session showing the issue:
> {code}
> cqlsh> CREATE KEYSPACE writetime_test WITH replication = {'class': 'SimpleStrategy','replication_factor': '1'};
> cqlsh> USE writetime_test;
> cqlsh:writetime_test> CREATE TABLE writetime_test_table (pk INT, ck INT, value INT, PRIMARY KEY (pk, ck));
> cqlsh:writetime_test> INSERT INTO writetime_test_table (pk, ck, value) VALUES (1, 2, null);
> cqlsh:writetime_test> SELECT WRITETIME(value) FROM writetime_test_table WHERE pk = 1 AND ck = 2;
>  writetime(value)
> ------------------
>              null
> (1 rows)
> cqlsh:writetime_test> INSERT INTO writetime_test_table (pk, ck, value) VALUES (2, 3, 4);
> cqlsh:writetime_test> SELECT WRITETIME(value) FROM writetime_test_table WHERE pk = 2 AND ck = 3;
>  writetime(value)
> ------------------
>  1389967663822000
> (1 rows)
> cqlsh:writetime_test> SELECT WRITETIME(value) FROM writetime_test_table WHERE pk = 3 AND ck = 4;
> (0 rows)
> {code}
> I first insert data where the cell value is {{null}}. When I query its writetime I get a row back, but the timestamp is {{null}}.
> I then insert a row with a value, and get a timestamp in the query results, as expected.
> Finally I query for the writetime of a cell that does not exist, and get no rows back, just to show that there's a difference between calling {{WRITETIME}} on {{null}} and on something that doesn't exist.
> Even though the value is {{null}} the cell exists and it has a timestamp. I can clearly see the timestamp using {{cassandra-cli}}:
> {code}
> [default@unknown] use writetime_test;
> Authenticated to keyspace: writetime_test
> [default@writetime_test] list writetime_test_table;
> Using default limit of 100
> Using default cell limit of 100
> -------------------
> RowKey: 1
> => (name=2:, value=, timestamp=1389967959822000)
> -------------------
> RowKey: 2
> => (name=3:, value=, timestamp=1389967964749000)
> => (name=3:value, value=00000004, timestamp=1389967964749000)
> {code}
> The reason I want to get the {{WRITETIME}} of a {{null}} value is that I have a table where I don't care about the value, I use the column keys as sorted set. I still want to know when some of them were written though, but I can't ask for the {{WRITETIME}} of something that is part of the primary key, so I must use the (otherwise unused) value.
> A workaround is to write some dummy value in the cell, and that's probably what I need to do, but this felt like it was a bug, it was at least not what I expected.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)