Documentation on a new CQL feature of 3.6

[Giampaolo Trapasso <gi...@radicalbit.io>]

Hi to all,

DS Documentation says that
*In Cassandra 3.6 and later, clustering columns can be defined in WHERE
clauses if ALLOW FILTERING is also used even if a secondary index is not
created. The table definition is given and then the SELECT command. Note
that race_start_date is a clustering column that has no secondary index.*

This seemed strange to me, since since in past I did queries using
clustering columns.

I did this quick check:

cqlsh:test> show version
[cqlsh 5.0.1 | Cassandra 2.2.5-SNAPSHOT | CQL spec 3.3.1 | Native protocol
v4]
cqlsh:test> SELECT * FROM calendar WHERE race_start_date='2015-06-13' ALLOW
FILTERING;

 race_id | race_start_date | race_end_date | race_name
---------+-----------------+---------------+-----------

(0 rows)
cqlsh:test> SELECT * FROM calendar WHERE race_end_date='2015-06-13' ALLOW
FILTERING;
InvalidRequest: code=2200 [Invalid query] message="PRIMARY KEY column
"race_end_date" cannot be restricted as preceding column "race_start_date"
is not restricted"
cqlsh:test>

As you can see, in < 3.6 you can put clustering columns in queries as long
as you respect the "preceding column" constraint. IMHO, that line should be
changed saying that an arbitrary clustering column can be used from 3.6,
and the example should use the 'race_end_date".

This is DS documentation. Did not find something similar in community
documentation (anycase 8700 is a work in progress, I will check in future).
Let me know if I'm missing some point.

Giampaolo

Re: Documentation on a new CQL feature of 3.6

[Oleksandr Petrov <ol...@gmail.com>]

As far as I understand this wording, it's correct. Prior to 3.6 *filtering*
was not allowed on clustering columns. It was allowed to do non-filtering
queries involving clustering columns, although you could not specify any
clustering column (or combine multiple range queries). Now it is allowed.

So the wording "clustering columns can be defined in WHERE clauses* if
ALLOW FILTERING is also used even if a secondary index is not created*" is
correct (emphasis to indicate the context you specified). Might be that
secondary index part sounded like the behaviour was somewhat similar before.

For the background, you can check
https://issues.apache.org/jira/browse/CASSANDRA-11310

Having that said, I'll add a little guide for querying capabilities for the
current version in scope of 8700.

Thank you

On Wed, Jun 15, 2016 at 5:03 PM Giampaolo Trapasso <
giampaolo.trapasso@radicalbit.io> wrote:

> Hi to all,
>
> DS Documentation says that
> *In Cassandra 3.6 and later, clustering columns can be defined in WHERE
> clauses if ALLOW FILTERING is also used even if a secondary index is not
> created. The table definition is given and then the SELECT command. Note
> that race_start_date is a clustering column that has no secondary index.*
>
> This seemed strange to me, since since in past I did queries using
> clustering columns.
>
> I did this quick check:
>
> cqlsh:test> show version
> [cqlsh 5.0.1 | Cassandra 2.2.5-SNAPSHOT | CQL spec 3.3.1 | Native protocol
> v4]
> cqlsh:test> SELECT * FROM calendar WHERE race_start_date='2015-06-13' ALLOW
> FILTERING;
>
>  race_id | race_start_date | race_end_date | race_name
> ---------+-----------------+---------------+-----------
>
> (0 rows)
> cqlsh:test> SELECT * FROM calendar WHERE race_end_date='2015-06-13' ALLOW
> FILTERING;
> InvalidRequest: code=2200 [Invalid query] message="PRIMARY KEY column
> "race_end_date" cannot be restricted as preceding column "race_start_date"
> is not restricted"
> cqlsh:test>
>
> As you can see, in < 3.6 you can put clustering columns in queries as long
> as you respect the "preceding column" constraint. IMHO, that line should be
> changed saying that an arbitrary clustering column can be used from 3.6,
> and the example should use the 'race_end_date".
>
> This is DS documentation. Did not find something similar in community
> documentation (anycase 8700 is a work in progress, I will check in future).
> Let me know if I'm missing some point.
>
> Giampaolo
>
-- 
Alex Petrov