Ankou76ers commented on a change in pull request #1380:
URL: https://github.com/apache/cassandra/pull/1380#discussion_r794356278
##########
File path: src/java/org/apache/cassandra/cql3/conditions/ColumnCondition.java
##########
@@ -531,6 +534,25 @@ private static boolean setOrListAppliesTo(AbstractType<?>
type, Iterator<Cell<?>
return operator == Operator.EQ || operator == Operator.LTE ||
operator == Operator.GTE;
}
+ private static boolean valueAppliesTo(Iterator<Cell<?>> iter,
ByteBuffer value, boolean appliesToSetOrMapKeys)
+ {
+ while(iter.hasNext())
+ {
+ // for lists and map values we use the cell value; for sets
and map keys we use the cell name
+ ByteBuffer cellValue = appliesToSetOrMapKeys ?
iter.next().path().get(0) : iter.next().buffer();
+ int comparison = BytesType.instance.compare(cellValue, value);
Review comment:
I'm not sure about this, it seems to me that use of the
compareWithOperator method is related to the nature of the column of the
condition. It's a general behavior of the SimpleColumnCondition; if the target
column is a multicell collection it uses a MultiCellCollectionBound that not
relies on the compareWithOperator, if not it uses a SimpleBound that relies on
it.
So a "CONTAINS" clause on a frozen collection will use a SimpleBound and the
compareWithOperator method but the same clause on a non frozen collection will
use a MultiCellCollectionBound (and this specific compare code)
Maybe I miss something but it seems that a change at this level will have a
much bigger impact on existing code (impact I tried to limit for the moment).
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
