[
https://issues.apache.org/jira/browse/CASSANDRA-7304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oded Peer updated CASSANDRA-7304:
---------------------------------
Attachment: 4476-5.patch
[~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)
