[
https://issues.apache.org/jira/browse/CASSANDRA-5956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
DOAN DuyHai updated CASSANDRA-5956:
-----------------------------------
Description:
Right now I am preparing some slides for a talk and tutorial on Cassandra to
convince people switching from Thrift to CQL3. However I am facing issues
because of the limitation of CQL3 not being able to allow inequality on more
than 1 clustered component at a time.
My example is quite trivial. Let's consider a table to collect daily metrics
{code:sql}
CREATE TABLE daily_metrics
(
day int, // day in YYYYMMDD format
hour int,
minute int,
second int,
metrics blob,
PRIMARY KEY (day, hour, minute, second)
)
{code}
I should be able to grep all metrics from a range of date
// select all metrics from 8:30am to 10am
{code:sql}
SELECT metrics FROM daily_metrics WHERE day = 20130828 AND hour >= 8 AND
minute >= 30 and hour <= 10
{code}
// select all metrics of the day from 6:30pm
{code:sql}
SELECT metrics FROM daily_metrics WHERE day = 20130828 AND hour >= 18 AND
minute >= 30
{code}
Right now it is just IMPOSSIBLE to do this kind of query with CQL3, which is
PITA. We always get the error message
{quote}
Bad Request: PRIMARY KEY part minute cannot be restricted (preceding part hour
is either not restricted or by a non-EQ relation)
{quote}
Of course the example is trivial and I can just model the timestamp with 1
component by sticking hour, minute and second together. However the limitation
is still there and indeed there is no technical limitation to allow such a
query, except from some effort in CQL3 parsing and validation.
I know that there is already jira
[CASSANDRA-4415|https://issues.apache.org/jira/browse/CASSANDRA-4415] which is
a really good idea and also
[CASSANDRA-4851|https://issues.apache.org/jira/browse/CASSANDRA-4851] but the
issue raised above is *beyond the scope of just paging data*.
People are using more and more compound primary keys to model with Cassandra
and they should be able to do slice queries with inequality from all compound
components.
was:
Right now I am preparing some slides for a talk and tutorial on Cassandra to
convince people switching from Thrift to CQL3. However I am facing serious
issue because of the limitation of CQL3 not being able to allow inequality on
more than 1 clustered component at a time.
My example is quite trivial. Let's consider a table to collect daily metrics
{code:sql}
CREATE TABLE daily_metrics
(
day int, // day in YYYYMMDD format
hour int,
minute int,
second int,
metrics blob,
PRIMARY KEY (day, hour, minute, second)
)
{code}
I should be able to grep all metrics from a range of date
// select all metrics from 8:30am to 10am
{code:sql}
SELECT metrics FROM daily_metrics WHERE day = 20130828 AND hour >= 8 AND
minute >= 30 and hour <= 10
{code}
// select all metrics of the day from 6:30pm
{code:sql}
SELECT metrics FROM daily_metrics WHERE day = 20130828 AND hour >= 18 AND
minute >= 30
{code}
Right now it is just IMPOSSIBLE to do this kind of query with CQL3, which is
PITA. We always get the error message
{quote}
Bad Request: PRIMARY KEY part minute cannot be restricted (preceding part hour
is either not restricted or by a non-EQ relation)
{quote}
I know that there is already jira
[CASSANDRA-4415|https://issues.apache.org/jira/browse/CASSANDRA-4415] which is
a really good idea and also
[CASSANDRA-4851|https://issues.apache.org/jira/browse/CASSANDRA-4851] but the
issue raised above is *beyond the scope of just paging data*.
People are using more and more compound primary keys to model with Cassandra
and they should be able to do slice queries with inequality from all compound
components.
There are lots of use cases where such usage is required.
> Allow filtering on more than 1 clustered components
> ---------------------------------------------------
>
> Key: CASSANDRA-5956
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5956
> Project: Cassandra
> Issue Type: Improvement
> Components: API, Core
> Reporter: DOAN DuyHai
> Priority: Minor
>
> Right now I am preparing some slides for a talk and tutorial on Cassandra to
> convince people switching from Thrift to CQL3. However I am facing issues
> because of the limitation of CQL3 not being able to allow inequality on more
> than 1 clustered component at a time.
> My example is quite trivial. Let's consider a table to collect daily metrics
> {code:sql}
> CREATE TABLE daily_metrics
> (
> day int, // day in YYYYMMDD format
> hour int,
> minute int,
> second int,
> metrics blob,
> PRIMARY KEY (day, hour, minute, second)
> )
> {code}
> I should be able to grep all metrics from a range of date
> // select all metrics from 8:30am to 10am
> {code:sql}
> SELECT metrics FROM daily_metrics WHERE day = 20130828 AND hour >= 8 AND
> minute >= 30 and hour <= 10
> {code}
> // select all metrics of the day from 6:30pm
> {code:sql}
> SELECT metrics FROM daily_metrics WHERE day = 20130828 AND hour >= 18 AND
> minute >= 30
> {code}
> Right now it is just IMPOSSIBLE to do this kind of query with CQL3, which is
> PITA. We always get the error message
> {quote}
> Bad Request: PRIMARY KEY part minute cannot be restricted (preceding part
> hour is either not restricted or by a non-EQ relation)
> {quote}
> Of course the example is trivial and I can just model the timestamp with 1
> component by sticking hour, minute and second together. However the
> limitation is still there and indeed there is no technical limitation to
> allow such a query, except from some effort in CQL3 parsing and validation.
> I know that there is already jira
> [CASSANDRA-4415|https://issues.apache.org/jira/browse/CASSANDRA-4415] which
> is a really good idea and also
> [CASSANDRA-4851|https://issues.apache.org/jira/browse/CASSANDRA-4851] but the
> issue raised above is *beyond the scope of just paging data*.
> People are using more and more compound primary keys to model with Cassandra
> and they should be able to do slice queries with inequality from all compound
> components.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
