[
https://issues.apache.org/jira/browse/CASSANDRA-6875?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13986466#comment-13986466
]
Sylvain Lebresne commented on CASSANDRA-6875:
---------------------------------------------
bq. we can't use prepared statements with the dtests right now (as far as I can
tell)
We can, see cql_prepared_test.py (arguably our number of tests for prepared
statement is deeply lacking, but it's possible to have some).
On the more general question of where tests should go, we could have a debate I
suppose (but definitively not here), but frankly, I don't think there is very
many downside to having the tests in the dtests and since we have tons of them
there already, I'd much rather not waste precious time at changing for the sake
of change. But quickly, the reasons why I think dtests are really not that bad
here:
# it doesn't get a whole lot more end-to-end than the CQL tests imo.
# dtests feels to me a lot more readable and easier to work with. Mainly
because for that kind of tests python is just more comfortable/quick to get
things done.
# there *is* a few of the CQL dtests where we do want a distributed setup, like
CAS tests. Of course we could left those in dtests and move the rest in the
unit test suite, but keeping all CQL tests at the same place just feels simpler
(you don't duplicate all those small utility functions that you invariably need
to make tests easier).
# I work with unit tests and dtests daily, and it honestly is not at all my
experience that working with unit tests is a "lot faster". Quite the contrary
in fact. I'm willing to admit that one may be more comfortable with one suite
or the other, but I'll fight to the death the concept that "unit test are a
*lot* faster to work with" as an absolute truth.
I'll note the CQL dtests are not perfect. They could use being reorganized a
bit, and we can speed them up dramatically by not spinning up a cluster on
every test. That said, fixing those issue is likely simpler than migrating all
the existing tests back to the unit tests.
All this said, to focus back on this issue, I'd rather keep CQL tests to dtests
for now (even if we do start a debate on changing that fact on dev list), but I
won't block the issue if that's not the case. That remark was in the category
"minor comments".
> CQL3: select multiple CQL rows in a single partition using IN
> -------------------------------------------------------------
>
> Key: CASSANDRA-6875
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6875
> Project: Cassandra
> Issue Type: Bug
> Components: API
> Reporter: Nicolas Favre-Felix
> Assignee: Tyler Hobbs
> Priority: Minor
> Fix For: 2.0.8
>
>
> In the spirit of CASSANDRA-4851 and to bring CQL to parity with Thrift, it is
> important to support reading several distinct CQL rows from a given partition
> using a distinct set of "coordinates" for these rows within the partition.
> CASSANDRA-4851 introduced a range scan over the multi-dimensional space of
> clustering keys. We also need to support a "multi-get" of CQL rows,
> potentially using the "IN" keyword to define a set of clustering keys to
> fetch at once.
> (reusing the same example\:)
> Consider the following table:
> {code}
> CREATE TABLE test (
> k int,
> c1 int,
> c2 int,
> PRIMARY KEY (k, c1, c2)
> );
> {code}
> with the following data:
> {code}
> k | c1 | c2
> ---+----+----
> 0 | 0 | 0
> 0 | 0 | 1
> 0 | 1 | 0
> 0 | 1 | 1
> {code}
> We can fetch a single row or a range of rows, but not a set of them:
> {code}
> > SELECT * FROM test WHERE k = 0 AND (c1, c2) IN ((0, 0), (1,1)) ;
> Bad Request: line 1:54 missing EOF at ','
> {code}
> Supporting this syntax would return:
> {code}
> k | c1 | c2
> ---+----+----
> 0 | 0 | 0
> 0 | 1 | 1
> {code}
> Being able to fetch these two CQL rows in a single read is important to
> maintain partition-level isolation.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
