0

I have 2 c*4 nodes. And a secondary index provisioned.

./nodetool ring
192.168.43.10       rack1       Up     Normal  176.08 KiB      55.56%              4716404817677783992
192.168.43.11       rack1       Up     Normal  194.74 KiB      44.44%              6854338132896405748
./bin/cqlsh 192.168.43.10

If I query secondary index field with token(4716404817677783992) rows are correct

select * from x."y" where "a"='***' and token("Id")=6854338132896405748;

But if I query with token("Id")=6854338132896405748 result is zero, there are no exceptions in any node. Have an idea?

Secondary index implementation founds Ids and from 3rd party source and collects rows from c*

Both scenarios working on c*3

I realized that c4 is applying CQLFilter(RowFilter:330) but c3 not.

node1 (sends a="x:1")-> node2 -> 3rd party

3rd pary -> node2 (here adding field to response row a="total:5..")-> node1

node1 checks "a=x:1" with "a=total=5" in c4 but no check in c3. because of this check rows are filtered out. Any idea is this configurable? or a new security feature ?

2 Answers 2

1

Can you add token() to your select:

select a, id, token(id) from x."y" where "a"='***';

Might help to see what those hashed token values are, it might be different between versions. Change that query up if necessary.

0

Querying by an indexed column AND a token value makes no sense at all and I'm not sure what you're trying to achieve with your query.

As a matter of fact, a query with a filter on the tokenised id value:

SELECT * FROM table WHERE token(id)=6854338132896405748

makes no sense. If you already know the partition key then just use it directly in the filter:

SELECT * FROM table WHERE id = ?

Cassandra's partitioner will tokenise the partition key without you needing to know in advance what the token value is. Did I misunderstand your question?

As a side note, welcome to Stack Exchange! A friendly note to let you know your question is missing a few details. The general guidance is that you (a) provide a good summary of the problem that includes software/component versions, the full error message + full stack trace; (b) describe what you've tried to fix the problem, details of investigation you've done; and (c) steps to replicate the problem.

In your case, you should provide:

  • sample table schema
  • minimal sample data for replicating the issue
  • CQL query that works + sample output
  • CQL query that does not work
  • expected result/output
  • actual result/output

Providing the right information will make it easy for others to help. If others don't understand your question, you are unlikely to get help. Cheers!

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.