[jira] [Issue Comment Deleted] (CASSANDRA-7304) Ability to distinguish between NULL and UNSET values in Prepared Statements

["Oded Peer (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/CASSANDRA-7304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Oded Peer updated CASSANDRA-7304:
---------------------------------
    Comment: was deleted

(was: [~blerer]

Added 4476-5.patch

I updated the code to scan a restricted range if there are two expressions on the same column.


{quote}I think that you should use isRange or isSlice instead of isRelationalOrderOperator as it is clearer.{quote}
I renamed the method.

{quote}The name of test class: SecondaryIndexNonEqTest is misleading. CONTAINS an CONTAINS KEY operator are also non eq tests.{quote}
I renamed the test.

{quote}In getRelationalOrderEstimatedSize I do not understand why you do not return 0 if estimatedKeysForRange return 0. Could you explain?{quote}
I added comments to the code since I think it should documented in the code and not in Jira.
I hope it is understandable.

{quote}Instead of doing some dangerous casting in getRelationalOrderEstimatedSize, you should change the type from bestMeanCount from int to long.{quote}
I changed the type of bestMeanCount

{quote}In computeNext I do not understand why you do not check for stale data for range queries? Could you explain?{quote}
I added comments to the code.

{quote}I think it would be nicer to have also an iterator for EQ and use polymorphism instead of if else.{quote}
Generally I agree polymorphism is good practice, however I think in this case it would make the code less readable.

{quote}The close method of the AbstractScanIterator returned by getSequentialIterator should be called from the close method.{quote}
Thanks. I wasn't aware the iterator is closeable, they usually aren't.

{quote}The Unit tests are only covering a subset of the possible queries. Could you add more (a > 3 and a <4, a < 3 and a > 4 ...){quote}
Added.

{quote}When testing for InvalidRequestException you should use assertInvalidMessage{quote}
Thanks, I wanted to use such a method but couldn't find it on my own.

[~jjordan]

I don't understand the problem in your example. The query result seems valid to me.
In addition, can you please explain how a query using only secondary indexes such as {{select k from my_table where index1 = 5 and index2 > 10 allow filtering}} retains token order?)

> Ability to distinguish between NULL and UNSET values in Prepared Statements
> ---------------------------------------------------------------------------
>
>                 Key: CASSANDRA-7304
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-7304
>             Project: Cassandra
>          Issue Type: Sub-task
>            Reporter: Drew Kutcharian
>            Assignee: Oded Peer
>              Labels: cql, protocolv4
>             Fix For: 3.0
>
>         Attachments: 7304-03.patch, 7304-2.patch, 7304.patch
>
>
> Currently Cassandra inserts tombstones when a value of a column is bound to NULL in a prepared statement. At higher insert rates managing all these tombstones becomes an unnecessary overhead. This limits the usefulness of the prepared statements since developers have to either create multiple prepared statements (each with a different combination of column names, which at times is just unfeasible because of the sheer number of possible combinations) or fall back to using regular (non-prepared) statements.
> This JIRA is here to explore the possibility of either:
> A. Have a flag on prepared statements that once set, tells Cassandra to ignore null columns
> or
> B. Have an "UNSET" value which makes Cassandra skip the null columns and not tombstone them
> Basically, in the context of a prepared statement, a null value means delete, but we don’t have anything that means "ignore" (besides creating a new prepared statement without the ignored column).
> Please refer to the original conversation on DataStax Java Driver mailing list for more background:
> https://groups.google.com/a/lists.datastax.com/d/topic/java-driver-user/cHE3OOSIXBU/discussion



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)