cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Taiyuan Zhang (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (CASSANDRA-10958) Range query with filtering interacts badly with static columns
Date Fri, 08 Jan 2016 22:52:39 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-10958?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15090127#comment-15090127
] 

Taiyuan Zhang edited comment on CASSANDRA-10958 at 1/8/16 10:52 PM:
--------------------------------------------------------------------

The cause of this bizarre out is the following code:

{code:title=SelectStatement.java}
        // If there is no rows, then provided the select was a full partition selection
        // (i.e. not a 2ndary index search and there was no condition on clustering columns),
        // we want to include static columns and we're done.
        if (!partition.hasNext())
        {
            if (!staticRow.isEmpty() && (!restrictions.usesSecondaryIndexing() ||
cfm.isStaticCompactTable()) && !restrictions.hasClusteringColumnsRestriction())
            {
                result.newRow(protocolVersion);
                for (ColumnDefinition def : selection.getColumns())
                {
                    switch (def.kind)
                    {
                        case PARTITION_KEY:
                            result.add(keyComponents[def.position()]);
                            break;
                        case STATIC:
                            addValue(result, def, staticRow, nowInSec, protocolVersion);
                            break;
                        default:
                            result.add((ByteBuffer)null);
                    }
                }
            }
            return;
        }
{code}

Why do we need to keep the static row? Can anyone give me a case where we need to keep the
static row?


was (Author: firstprayer):
The cause of this bizarre out is the following code:

{code}
        // If there is no rows, then provided the select was a full partition selection
        // (i.e. not a 2ndary index search and there was no condition on clustering columns),
        // we want to include static columns and we're done.
        if (!partition.hasNext())
        {
            if (!staticRow.isEmpty() && (!restrictions.usesSecondaryIndexing() ||
cfm.isStaticCompactTable()) && !restrictions.hasClusteringColumnsRestriction())
            {
                result.newRow(protocolVersion);
                for (ColumnDefinition def : selection.getColumns())
                {
                    switch (def.kind)
                    {
                        case PARTITION_KEY:
                            result.add(keyComponents[def.position()]);
                            break;
                        case STATIC:
                            addValue(result, def, staticRow, nowInSec, protocolVersion);
                            break;
                        default:
                            result.add((ByteBuffer)null);
                    }
                }
            }
            return;
        }
{code}

Why do we need to keep the static row? Can anyone give me a case where we need to keep the
static row?

> Range query with filtering interacts badly with static columns
> --------------------------------------------------------------
>
>                 Key: CASSANDRA-10958
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-10958
>             Project: Cassandra
>          Issue Type: Bug
>            Reporter: Taiyuan Zhang
>            Priority: Minor
>
>  I'm playing with Cassandra 3. I added a secondary index on a column of integer, then
I want to do a range query. First it threw an error:
> {code}
> InvalidRequest: code=2200 [Invalid query] message="No supported secondary index found
for the non primary key columns restrictions"
> {code}
> So I added 'Allow Filtering'
> {code}
>     cqlsh:mykeyspace> SELECT * FROM test ;
>     id | id2 | age | extra
>     ----+-----+-----+-------
>       1 |   1 |   1 |     1
>       2 |   2 |   2 |     2
>     (2 rows)
>     cqlsh:mykeyspace > CREATE INDEX test_age on test (extra) ;
>     cqlsh:mykeyspace > select * FROM test WHERE extra < 2 ALLOW FILTERING ;
>      id | id2  | age | extra
>     ----+------+-----+-------
>       1 |    1 |   1 |     1
>       2 | null |   2 |  null
>     (2 rows)
> {code}
> My schema is:
> {code}
>     CREATE TABLE mykeyspace.test (
>     id int,
>     id2 int,
>     age int static,
>     extra int,
>     PRIMARY KEY (id, id2)
>     ) 
> {code}
> I don't know if this is by design or not, but it really does look like a BUG to me.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message