cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-6875) CQL3: select multiple CQL rows in a single partition using IN
Date Thu, 01 May 2014 09:37:17 GMT


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 (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:
>             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}
>   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

This message was sent by Atlassian JIRA

View raw message