[
https://issues.apache.org/jira/browse/CASSANDRA-18896?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-18896:
----------------------------------------
Attachment: result_details.tar.gz
> ClientRequestSize metrics should not treat CONTAINS restrictions as being
> equality-based
> ----------------------------------------------------------------------------------------
>
> Key: CASSANDRA-18896
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18896
> Project: Cassandra
> Issue Type: Improvement
> Components: Observability/Metrics
> Reporter: Caleb Rackliffe
> Assignee: Caleb Rackliffe
> Priority: Normal
> Fix For: 5.0-alpha2, 5.1
>
> Attachments: ci_summary.html, result_details.tar.gz
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> The following behavior needs to be changed to consider the column restricted
> by {{CONTAINS}} or {{CONTAINS KEY}} as "read", rather than "provided by the
> client". We already do this for things like range restrictions, and the
> current behavior is inconsistent.
> {noformat}
> @Test
> public void shouldRecordReadMetricsForContainsQuery() throws Throwable
> {
> createTable("CREATE TABLE %s (pk int, ck int, v set<int>, PRIMARY KEY
> (pk, ck))");
> executeNet(CURRENT, "INSERT INTO %s (pk, ck, v) VALUES (1, 1, {1, 2, 3}
> )");
> executeNet(CURRENT, "INSERT INTO %s (pk, ck, v) VALUES (2, 2, {4, 5,
> 6})");
> executeNet(CURRENT, "SELECT * FROM %s WHERE v CONTAINS 1 ALLOW
> FILTERING");
> assertEquals(1, ClientRequestSizeMetrics.totalRowsRead.getCount());
> // The filtering term is provided by the client in the request, so we
> don't consider that column read.
> assertEquals(2, ClientRequestSizeMetrics.totalColumnsRead.getCount());
> }
> {noformat}
> The fix should be literally two lines, one in {{SingleRestriction}} and one
> in the test above.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]