[jira] [Issue Comment Deleted] (CASSANDRA-10965) Shadowable tombstones can continue to shadow view results when timestamps match
[
https://issues.apache.org/jira/browse/CASSANDRA-10965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Taiyuan Zhang updated CASSANDRA-10965:
--
Comment: was deleted
(was: It's been a while and it seems the output of the given cql is changed:
When I execute
{code}
INSERT INTO base (k, c, val) VALUES (1, 1, 1) USING TIMESTAMP 0;
SELECT c, k, val FROM base; SELECT c, k, val FROM mv_reuse;
UPDATE base USING TIMESTAMP 1 SET c = 0 WHERE k = 1;
SELECT c, k, val FROM base; SELECT c, k, val FROM mv_reuse;
UPDATE base USING TIMESTAMP 1 SET c = 1 WHERE k = 1;
{code}
The output is
{code}
cqlsh:mykeyspace> INSERT INTO base (k, c, val) VALUES (1, 1, 1) USING TIMESTAMP
0;
cqlsh:mykeyspace> select * FROM mv_reuse ; SELECT * FROM mv_reuse ;
k | c | val
---+---+-
1 | 1 | 1
(1 rows)
k | c | val
---+---+-
1 | 1 | 1
(1 rows)
cqlsh:mykeyspace> UPDATE base USING TIMESTAMP 1 SET c = 0 WHERE k = 1;
cqlsh:mykeyspace> select * FROM mv_reuse ; SELECT * FROM mv_reuse ;
k | c | val
---+---+-
1 | 0 | 1
(1 rows)
k | c | val
---+---+-
1 | 0 | 1
(1 rows)
cqlsh:mykeyspace> UPDATE base USING TIMESTAMP 1 SET c = 1 WHERE k = 1;
cqlsh:mykeyspace> select * FROM mv_reuse ; SELECT * FROM mv_reuse ;
k | c | val
---+---+-
(0 rows)
k | c | val
---+---+-
(0 rows)
{code}
So previously, the updated row will appear when selecting from the base, but
disappears when selecting from the view; now, it shows from neither select
query.
So, just to confirm, the correct, expected behavior should be: the row k=1,
c=1, val=1 should appears in BOTH select query (from base and from the view),
right?)
> Shadowable tombstones can continue to shadow view results when timestamps
> match
> ---
>
> Key: CASSANDRA-10965
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10965
> Project: Cassandra
> Issue Type: Bug
> Components: Local Write-Read Paths
>Reporter: Carl Yeksigian
>Assignee: Carl Yeksigian
> Fix For: 3.0.x
>
> Attachments: shadow-ts.cql
>
>
> I've attached a script which reproduces the issue. The first time we insert
> with {{TIMESTAMP 2}}, we are inserting a new row which has the same timestamp
> as the previous shadow tombstone, and it continues to be shadowed by that
> tombstone because we shadow values with the same timestamp.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10965) Shadowable tombstones can continue to shadow view results when timestamps match
[
https://issues.apache.org/jira/browse/CASSANDRA-10965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15109829#comment-15109829
]
Taiyuan Zhang commented on CASSANDRA-10965:
---
It's been a while and it seems the output of the given cql is changed:
When I execute
{code}
INSERT INTO base (k, c, val) VALUES (1, 1, 1) USING TIMESTAMP 0;
SELECT c, k, val FROM base; SELECT c, k, val FROM mv_reuse;
UPDATE base USING TIMESTAMP 1 SET c = 0 WHERE k = 1;
SELECT c, k, val FROM base; SELECT c, k, val FROM mv_reuse;
UPDATE base USING TIMESTAMP 1 SET c = 1 WHERE k = 1;
{code}
The output is
{code}
cqlsh:mykeyspace> INSERT INTO base (k, c, val) VALUES (1, 1, 1) USING TIMESTAMP
0;
cqlsh:mykeyspace> select * FROM mv_reuse ; SELECT * FROM mv_reuse ;
k | c | val
---+---+-
1 | 1 | 1
(1 rows)
k | c | val
---+---+-
1 | 1 | 1
(1 rows)
cqlsh:mykeyspace> UPDATE base USING TIMESTAMP 1 SET c = 0 WHERE k = 1;
cqlsh:mykeyspace> select * FROM mv_reuse ; SELECT * FROM mv_reuse ;
k | c | val
---+---+-
1 | 0 | 1
(1 rows)
k | c | val
---+---+-
1 | 0 | 1
(1 rows)
cqlsh:mykeyspace> UPDATE base USING TIMESTAMP 1 SET c = 1 WHERE k = 1;
cqlsh:mykeyspace> select * FROM mv_reuse ; SELECT * FROM mv_reuse ;
k | c | val
---+---+-
(0 rows)
k | c | val
---+---+-
(0 rows)
{code}
So previously, the updated row will appear when selecting from the base, but
disappears when selecting from the view; now, it shows from neither select
query.
So, just to confirm, the correct, expected behavior should be: the row k=1,
c=1, val=1 should appears in BOTH select query (from base and from the view),
right?
> Shadowable tombstones can continue to shadow view results when timestamps
> match
> ---
>
> Key: CASSANDRA-10965
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10965
> Project: Cassandra
> Issue Type: Bug
> Components: Local Write-Read Paths
>Reporter: Carl Yeksigian
>Assignee: Carl Yeksigian
> Fix For: 3.0.x
>
> Attachments: shadow-ts.cql
>
>
> I've attached a script which reproduces the issue. The first time we insert
> with {{TIMESTAMP 2}}, we are inserting a new row which has the same timestamp
> as the previous shadow tombstone, and it continues to be shadowed by that
> tombstone because we shadow values with the same timestamp.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8103) Secondary Indices for Static Columns
[ https://issues.apache.org/jira/browse/CASSANDRA-8103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Taiyuan Zhang updated CASSANDRA-8103: - Attachment: (was: 8103-v3.patch) > Secondary Indices for Static Columns > > > Key: CASSANDRA-8103 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8103 > Project: Cassandra > Issue Type: New Feature > Components: CQL >Reporter: Ron Cohen >Assignee: Taiyuan Zhang > Fix For: 3.x > > Attachments: 8103-v4.patch, 8103.patch, in_progress.patch, > smoke-test.cql > > > We should add secondary index support for static columns. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8103) Secondary Indices for Static Columns
[ https://issues.apache.org/jira/browse/CASSANDRA-8103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Taiyuan Zhang updated CASSANDRA-8103: - Attachment: 8103-v4.patch Just solved some errors in tests and here's the updated patch (v4). > Secondary Indices for Static Columns > > > Key: CASSANDRA-8103 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8103 > Project: Cassandra > Issue Type: New Feature > Components: CQL >Reporter: Ron Cohen >Assignee: Taiyuan Zhang > Fix For: 3.x > > Attachments: 8103-v3.patch, 8103-v4.patch, 8103.patch, > in_progress.patch, smoke-test.cql > > > We should add secondary index support for static columns. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8103) Secondary Indices for Static Columns
[ https://issues.apache.org/jira/browse/CASSANDRA-8103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Taiyuan Zhang updated CASSANDRA-8103: - Attachment: 8103-v3.patch Thanks for the comment. Updated as suggested (8103-v3.patch). > Secondary Indices for Static Columns > > > Key: CASSANDRA-8103 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8103 > Project: Cassandra > Issue Type: New Feature > Components: CQL >Reporter: Ron Cohen >Assignee: Taiyuan Zhang > Fix For: 3.x > > Attachments: 8103-v3.patch, 8103.patch, in_progress.patch, > smoke-test.cql > > > We should add secondary index support for static columns. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8103) Secondary Indices for Static Columns
[ https://issues.apache.org/jira/browse/CASSANDRA-8103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Taiyuan Zhang updated CASSANDRA-8103: - Attachment: (was: 8103-v2.patch) > Secondary Indices for Static Columns > > > Key: CASSANDRA-8103 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8103 > Project: Cassandra > Issue Type: New Feature > Components: CQL >Reporter: Ron Cohen >Assignee: Taiyuan Zhang > Fix For: 3.x > > Attachments: 8103.patch, in_progress.patch, smoke-test.cql > > > We should add secondary index support for static columns. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-8103) Secondary Indices for Static Columns
[ https://issues.apache.org/jira/browse/CASSANDRA-8103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15104172#comment-15104172 ] Taiyuan Zhang edited comment on CASSANDRA-8103 at 1/18/16 4:53 AM: --- I added a new patch (the 8103-v2.patch). In this new patch I made modifications based on the suggestions of [~beobal]. Notes: this patch borrows some codes from my patch at issue 10958. That patch is not approved yet - but if this patched is merged, then that 10958 patch is no longer needed. was (Author: firstprayer): I added a new patch. In this new patch I made modifications based on the suggestions of [~beobal]. Notes: this patch borrows some codes from my patch at issue 10958. That patch is not approved yet - but if this patched is merged, then that 10958 patch is no longer needed. > Secondary Indices for Static Columns > > > Key: CASSANDRA-8103 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8103 > Project: Cassandra > Issue Type: New Feature > Components: CQL >Reporter: Ron Cohen >Assignee: Taiyuan Zhang > Fix For: 3.x > > Attachments: 8103-v2.patch, 8103.patch, in_progress.patch, > smoke-test.cql > > > We should add secondary index support for static columns. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10958) Range query with filtering interacts badly with static columns
[
https://issues.apache.org/jira/browse/CASSANDRA-10958?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15104175#comment-15104175
]
Taiyuan Zhang commented on CASSANDRA-10958:
---
The code of my patch is re-used by my patch for issue 8103. If that patch pass,
this patch is no longer need since it's contained at the 8103 patch.
> 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
>Assignee: Taiyuan Zhang
>Priority: Minor
> Attachments: 10958.patch
>
>
> 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)
[jira] [Updated] (CASSANDRA-8103) Secondary Indices for Static Columns
[ https://issues.apache.org/jira/browse/CASSANDRA-8103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Taiyuan Zhang updated CASSANDRA-8103: - Attachment: 8103-v2.patch I added a new patch. In this new patch I made modifications based on the suggestions of [~beobal]. Notes: this patch borrows some codes from my patch at issue 10958. That patch is not approved yet - but if this patched is merged, then that 10958 patch is no longer needed. > Secondary Indices for Static Columns > > > Key: CASSANDRA-8103 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8103 > Project: Cassandra > Issue Type: New Feature > Components: CQL >Reporter: Ron Cohen >Assignee: Taiyuan Zhang > Fix For: 3.x > > Attachments: 8103-v2.patch, 8103.patch, in_progress.patch, > smoke-test.cql > > > We should add secondary index support for static columns. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10958) Range query with filtering interacts badly with static columns
[
https://issues.apache.org/jira/browse/CASSANDRA-10958?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15103004#comment-15103004
]
Taiyuan Zhang commented on CASSANDRA-10958:
---
Any update here?
> 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
>Assignee: Taiyuan Zhang
>Priority: Minor
> Attachments: 10958.patch
>
>
> 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)
[jira] [Commented] (CASSANDRA-8103) Secondary Indices for Static Columns
[ https://issues.apache.org/jira/browse/CASSANDRA-8103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15097632#comment-15097632 ] Taiyuan Zhang commented on CASSANDRA-8103: -- Any feedback here? > Secondary Indices for Static Columns > > > Key: CASSANDRA-8103 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8103 > Project: Cassandra > Issue Type: New Feature > Components: CQL >Reporter: Ron Cohen > Fix For: 3.x > > Attachments: 8103.patch, in_progress.patch, smoke-test.cql > > > We should add secondary index support for static columns. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10965) Shadowable tombstones can continue to shadow view results when timestamps match
[
https://issues.apache.org/jira/browse/CASSANDRA-10965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15097388#comment-15097388
]
Taiyuan Zhang commented on CASSANDRA-10965:
---
I haven't started looking into this so I don't know how complicated the problem
is, but the time seems to fit into my calendar. I'll look into this in recent 1
or 2 days to better understand the problem and give a better estimation.
> Shadowable tombstones can continue to shadow view results when timestamps
> match
> ---
>
> Key: CASSANDRA-10965
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10965
> Project: Cassandra
> Issue Type: Bug
> Components: Local Write-Read Paths
>Reporter: Carl Yeksigian
>Assignee: Carl Yeksigian
> Fix For: 3.0.x
>
> Attachments: shadow-ts.cql
>
>
> I've attached a script which reproduces the issue. The first time we insert
> with {{TIMESTAMP 2}}, we are inserting a new row which has the same timestamp
> as the previous shadow tombstone, and it continues to be shadowed by that
> tombstone because we shadow values with the same timestamp.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10965) Shadowable tombstones can continue to shadow view results when timestamps match
[
https://issues.apache.org/jira/browse/CASSANDRA-10965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15093440#comment-15093440
]
Taiyuan Zhang commented on CASSANDRA-10965:
---
Got it. Are you currently working on this? If not, I'm interested in digging
into this.
> Shadowable tombstones can continue to shadow view results when timestamps
> match
> ---
>
> Key: CASSANDRA-10965
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10965
> Project: Cassandra
> Issue Type: Bug
> Components: Local Write-Read Paths
>Reporter: Carl Yeksigian
>Assignee: Carl Yeksigian
> Fix For: 3.0.x
>
> Attachments: shadow-ts.cql
>
>
> I've attached a script which reproduces the issue. The first time we insert
> with {{TIMESTAMP 2}}, we are inserting a new row which has the same timestamp
> as the previous shadow tombstone, and it continues to be shadowed by that
> tombstone because we shadow values with the same timestamp.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10958) Range query with filtering interacts badly with static columns
[
https://issues.apache.org/jira/browse/CASSANDRA-10958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Taiyuan Zhang updated CASSANDRA-10958:
--
Attachment: 10958.patch
> 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
> Attachments: 10958.patch
>
>
> 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)
[jira] [Comment Edited] (CASSANDRA-10965) Shadowable tombstones can continue to shadow view results when timestamps match
[
https://issues.apache.org/jira/browse/CASSANDRA-10965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15090159#comment-15090159
]
Taiyuan Zhang edited comment on CASSANDRA-10965 at 1/8/16 11:16 PM:
I ran the script, and here is the output:
{code}
cqlsh:mykeyspace> SELECT c, k, val FROM base; SELECT c, k, val FROM mv_reuse;
c | k | val
---+---+-
0 | 1 | 1
(1 rows)
c | k | val
---+---+-
0 | 1 | 1
(1 rows)
cqlsh:mykeyspace> UPDATE base USING TIMESTAMP 1 SET c = 1 WHERE k = 1;
cqlsh:mykeyspace> SELECT c, k, val FROM base; SELECT c, k, val FROM mv_reuse;
c | k | val
---+---+-
1 | 1 | 1
(1 rows)
c | k | val
---+---+-
(0 rows)
{code}
So the problem is: after the update using the same timestamp, the row is not
shown when query from the materialized view?
was (Author: firstprayer):
I ran the script, and here is the output:
{code}
cqlsh:mykeyspace> SELECT c, k, val FROM base; SELECT c, k, val FROM mv_reuse;
c | k | val
---+---+-
0 | 1 | 1
(1 rows)
c | k | val
---+---+-
0 | 1 | 1
(1 rows)
cqlsh:mykeyspace> UPDATE base USING TIMESTAMP 1 SET c = 1 WHERE k = 1;
cqlsh:mykeyspace> SELECT c, k, val FROM base; SELECT c, k, val FROM mv_reuse;
c | k | val
---+---+-
1 | 1 | 1
(1 rows)
c | k | val
---+---+-
{code}
So the problem is: after the update using the same timestamp, the row is not
shown when query from the materialized view?
> Shadowable tombstones can continue to shadow view results when timestamps
> match
> ---
>
> Key: CASSANDRA-10965
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10965
> Project: Cassandra
> Issue Type: Bug
> Components: Local Write-Read Paths
>Reporter: Carl Yeksigian
>Assignee: Carl Yeksigian
> Fix For: 3.0.x
>
> Attachments: shadow-ts.cql
>
>
> I've attached a script which reproduces the issue. The first time we insert
> with {{TIMESTAMP 2}}, we are inserting a new row which has the same timestamp
> as the previous shadow tombstone, and it continues to be shadowed by that
> tombstone because we shadow values with the same timestamp.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10965) Shadowable tombstones can continue to shadow view results when timestamps match
[
https://issues.apache.org/jira/browse/CASSANDRA-10965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15090159#comment-15090159
]
Taiyuan Zhang commented on CASSANDRA-10965:
---
I ran the script, and here is the output:
{code}
cqlsh:mykeyspace> SELECT c, k, val FROM base; SELECT c, k, val FROM mv_reuse;
c | k | val
---+---+-
0 | 1 | 1
(1 rows)
c | k | val
---+---+-
0 | 1 | 1
(1 rows)
cqlsh:mykeyspace> UPDATE base USING TIMESTAMP 1 SET c = 1 WHERE k = 1;
cqlsh:mykeyspace> SELECT c, k, val FROM base; SELECT c, k, val FROM mv_reuse;
c | k | val
---+---+-
1 | 1 | 1
(1 rows)
c | k | val
---+---+-
{code}
So the problem is: after the update using the same timestamp, the row is not
shown when query from the materialized view?
> Shadowable tombstones can continue to shadow view results when timestamps
> match
> ---
>
> Key: CASSANDRA-10965
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10965
> Project: Cassandra
> Issue Type: Bug
> Components: Local Write-Read Paths
>Reporter: Carl Yeksigian
>Assignee: Carl Yeksigian
> Fix For: 3.0.x
>
> Attachments: shadow-ts.cql
>
>
> I've attached a script which reproduces the issue. The first time we insert
> with {{TIMESTAMP 2}}, we are inserting a new row which has the same timestamp
> as the previous shadow tombstone, and it continues to be shadowed by that
> tombstone because we shadow values with the same timestamp.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-10958) Range query with filtering interacts badly with static columns
[
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)
[jira] [Commented] (CASSANDRA-10958) Range query with filtering interacts badly with static columns
[
https://issues.apache.org/jira/browse/CASSANDRA-10958?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15090127#comment-15090127
]
Taiyuan Zhang commented on CASSANDRA-10958:
---
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)
[jira] [Comment Edited] (CASSANDRA-10958) Range query with filtering interacts badly with static columns
[
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:51 PM:
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?
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)
[jira] [Commented] (CASSANDRA-10958) Range query with filtering interacts badly with static columns
[
https://issues.apache.org/jira/browse/CASSANDRA-10958?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15084934#comment-15084934
]
Taiyuan Zhang commented on CASSANDRA-10958:
---
I'll work on this then.
> 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)
[jira] [Updated] (CASSANDRA-8103) Secondary Indices for Static Columns
[ https://issues.apache.org/jira/browse/CASSANDRA-8103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Taiyuan Zhang updated CASSANDRA-8103: - Attachment: 8103.patch I have attached my patch for this issue. I added a new unit test. I'm kind of new to Cassandra so I don't know whether my approach is the most appropriate approach, so I'd welcome any comment/suggestions. Thanks. > Secondary Indices for Static Columns > > > Key: CASSANDRA-8103 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8103 > Project: Cassandra > Issue Type: New Feature > Components: CQL >Reporter: Ron Cohen >Assignee: Sam Tunnicliffe > Fix For: 3.x > > Attachments: 8103.patch, in_progress.patch, smoke-test.cql > > > We should add secondary index support for static columns. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10958) Range query using secondary index returns weird results
[
https://issues.apache.org/jira/browse/CASSANDRA-10958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Taiyuan Zhang updated CASSANDRA-10958:
--
Description:
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.
was:
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}
It certainly looks like a BUG to me, even though it has a chance to be
something by-design.
> Range query using secondary index returns weird results
> ---
>
> 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)
[jira] [Updated] (CASSANDRA-10958) Range query using secondary index returns weird results
[
https://issues.apache.org/jira/browse/CASSANDRA-10958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Taiyuan Zhang updated CASSANDRA-10958:
--
Description:
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'
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)
My schema is:
CREATE TABLE mykeyspace.test (
id int,
id2 int,
age int static,
extra int,
PRIMARY KEY (id, id2)
)
It certainly looks like a BUG to me, even though it has a chance to be
something by-design.
was:
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:
InvalidRequest: code=2200 [Invalid query] message="No supported secondary
index found for the non primary key columns restrictions"
So I added 'Allow Filtering'
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)
My schema is:
CREATE TABLE mykeyspace.test (
id int,
id2 int,
age int static,
extra int,
PRIMARY KEY (id, id2)
)
It certainly looks like a BUG to me, even though it has a chance to be
something by-design.
> Range query using secondary index returns weird results
> ---
>
> 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'
> 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)
> My schema is:
> CREATE TABLE mykeyspace.test (
> id int,
> id2 int,
> age int static,
> extra int,
> PRIMARY KEY (id, id2)
> )
> It certainly looks like a BUG to me, even though it has a chance to be
> something by-design.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10958) Range query using secondary index returns weird results
[
https://issues.apache.org/jira/browse/CASSANDRA-10958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Taiyuan Zhang updated CASSANDRA-10958:
--
Description:
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:shell}
InvalidRequest: code=2200 [Invalid query] message="No supported secondary index
found for the non primary key columns restrictions"
{code}
So I added 'Allow Filtering'
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)
My schema is:
CREATE TABLE mykeyspace.test (
id int,
id2 int,
age int static,
extra int,
PRIMARY KEY (id, id2)
)
It certainly looks like a BUG to me, even though it has a chance to be
something by-design.
was:
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'
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)
My schema is:
CREATE TABLE mykeyspace.test (
id int,
id2 int,
age int static,
extra int,
PRIMARY KEY (id, id2)
)
It certainly looks like a BUG to me, even though it has a chance to be
something by-design.
> Range query using secondary index returns weird results
> ---
>
> 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:shell}
> InvalidRequest: code=2200 [Invalid query] message="No supported secondary
> index found for the non primary key columns restrictions"
> {code}
> So I added 'Allow Filtering'
> 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)
> My schema is:
> CREATE TABLE mykeyspace.test (
> id int,
> id2 int,
> age int static,
> extra int,
> PRIMARY KEY (id, id2)
> )
> It certainly looks like a BUG to me, even though it has a chance to be
> something by-design.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10958) Range query using secondary index returns weird results
[
https://issues.apache.org/jira/browse/CASSANDRA-10958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Taiyuan Zhang updated CASSANDRA-10958:
--
Description:
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}
It certainly looks like a BUG to me, even though it has a chance to be
something by-design.
was:
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:shell}
InvalidRequest: code=2200 [Invalid query] message="No supported secondary index
found for the non primary key columns restrictions"
{code}
So I added 'Allow Filtering'
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)
My schema is:
CREATE TABLE mykeyspace.test (
id int,
id2 int,
age int static,
extra int,
PRIMARY KEY (id, id2)
)
It certainly looks like a BUG to me, even though it has a chance to be
something by-design.
> Range query using secondary index returns weird results
> ---
>
> 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}
> It certainly looks like a BUG to me, even though it has a chance to be
> something by-design.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CASSANDRA-10958) Range query using secondary index returns weird results
Taiyuan Zhang created CASSANDRA-10958: - Summary: Range query using secondary index returns weird results 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: InvalidRequest: code=2200 [Invalid query] message="No supported secondary index found for the non primary key columns restrictions" So I added 'Allow Filtering' 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) My schema is: CREATE TABLE mykeyspace.test ( id int, id2 int, age int static, extra int, PRIMARY KEY (id, id2) ) It certainly looks like a BUG to me, even though it has a chance to be something by-design. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10958) Range query using secondary index returns weird results
[ https://issues.apache.org/jira/browse/CASSANDRA-10958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Taiyuan Zhang updated CASSANDRA-10958: -- Description: 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: InvalidRequest: code=2200 [Invalid query] message="No supported secondary index found for the non primary key columns restrictions" So I added 'Allow Filtering' 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) My schema is: CREATE TABLE mykeyspace.test ( id int, id2 int, age int static, extra int, PRIMARY KEY (id, id2) ) It certainly looks like a BUG to me, even though it has a chance to be something by-design. was: 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: InvalidRequest: code=2200 [Invalid query] message="No supported secondary index found for the non primary key columns restrictions" So I added 'Allow Filtering' 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) My schema is: CREATE TABLE mykeyspace.test ( id int, id2 int, age int static, extra int, PRIMARY KEY (id, id2) ) It certainly looks like a BUG to me, even though it has a chance to be something by-design. > Range query using secondary index returns weird results > --- > > 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: > InvalidRequest: code=2200 [Invalid query] message="No supported secondary > index found for the non primary key columns restrictions" > So I added 'Allow Filtering' > 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) > My schema is: > CREATE TABLE mykeyspace.test ( > id int, > id2 int, > age int static, > extra int, > PRIMARY KEY (id, id2) > ) > It certainly looks like a BUG to me, even though it has a chance to be > something by-design. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8103) Secondary Indices for Static Columns
[ https://issues.apache.org/jira/browse/CASSANDRA-8103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15073346#comment-15073346 ] Taiyuan Zhang commented on CASSANDRA-8103: -- Hi all, I have attached a link to my working branch https://github.com/firstprayer/cassandra/tree/8103. Any comment is welcomed. I'm not sure I'm taking the most appropriate approach but it can work. I'll add the test cases later. Right now I just want to know if this is the right path to go with. > Secondary Indices for Static Columns > > > Key: CASSANDRA-8103 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8103 > Project: Cassandra > Issue Type: New Feature > Components: CQL >Reporter: Ron Cohen >Assignee: Sam Tunnicliffe > Fix For: 3.x > > Attachments: in_progress.patch, smoke-test.cql > > > We should add secondary index support for static columns. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10876) Alter behavior of batch WARN and fail on single partition batches
[ https://issues.apache.org/jira/browse/CASSANDRA-10876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15070578#comment-15070578 ] Taiyuan Zhang commented on CASSANDRA-10876: --- Just attached the file. Sorry. > Alter behavior of batch WARN and fail on single partition batches > - > > Key: CASSANDRA-10876 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10876 > Project: Cassandra > Issue Type: Improvement >Reporter: Patrick McFadin >Priority: Minor > Attachments: 10876.txt > > > In an attempt to give operator insight into potentially harmful batch usage, > Jiras were created to log WARN or fail on certain batch sizes. This ignores > the single partition batch, which doesn't create the same issues as a > multi-partition batch. > The proposal is to ignore size on single partition batch statements. > Reference: > [CASSANDRA-6487|https://issues.apache.org/jira/browse/CASSANDRA-6487] > [CASSANDRA-8011|https://issues.apache.org/jira/browse/CASSANDRA-8011] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10876) Alter behavior of batch WARN and fail on single partition batches
[ https://issues.apache.org/jira/browse/CASSANDRA-10876?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Taiyuan Zhang updated CASSANDRA-10876: -- Attachment: 10876.txt > Alter behavior of batch WARN and fail on single partition batches > - > > Key: CASSANDRA-10876 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10876 > Project: Cassandra > Issue Type: Improvement >Reporter: Patrick McFadin >Priority: Minor > Attachments: 10876.txt > > > In an attempt to give operator insight into potentially harmful batch usage, > Jiras were created to log WARN or fail on certain batch sizes. This ignores > the single partition batch, which doesn't create the same issues as a > multi-partition batch. > The proposal is to ignore size on single partition batch statements. > Reference: > [CASSANDRA-6487|https://issues.apache.org/jira/browse/CASSANDRA-6487] > [CASSANDRA-8011|https://issues.apache.org/jira/browse/CASSANDRA-8011] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10876) Alter behavior of batch WARN and fail on single partition batches
[ https://issues.apache.org/jira/browse/CASSANDRA-10876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15070201#comment-15070201 ] Taiyuan Zhang commented on CASSANDRA-10876: --- Attached a patch - it seems to be a really simple change, unless I misunderstood the issue... > Alter behavior of batch WARN and fail on single partition batches > - > > Key: CASSANDRA-10876 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10876 > Project: Cassandra > Issue Type: Improvement >Reporter: Patrick McFadin >Priority: Minor > > In an attempt to give operator insight into potentially harmful batch usage, > Jiras were created to log WARN or fail on certain batch sizes. This ignores > the single partition batch, which doesn't create the same issues as a > multi-partition batch. > The proposal is to ignore size on single partition batch statements. > Reference: > [CASSANDRA-6487|https://issues.apache.org/jira/browse/CASSANDRA-6487] > [CASSANDRA-8011|https://issues.apache.org/jira/browse/CASSANDRA-8011] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10876) Alter behavior of batch WARN and fail on single partition batches
[ https://issues.apache.org/jira/browse/CASSANDRA-10876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15070056#comment-15070056 ] Taiyuan Zhang commented on CASSANDRA-10876: --- To make sure I understand this correctly - single partition means single partition key, not single column family(table), right? > Alter behavior of batch WARN and fail on single partition batches > - > > Key: CASSANDRA-10876 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10876 > Project: Cassandra > Issue Type: Improvement >Reporter: Patrick McFadin >Priority: Minor > > In an attempt to give operator insight into potentially harmful batch usage, > Jiras were created to log WARN or fail on certain batch sizes. This ignores > the single partition batch, which doesn't create the same issues as a > multi-partition batch. > The proposal is to ignore size on single partition batch statements. > Reference: > [CASSANDRA-6487|https://issues.apache.org/jira/browse/CASSANDRA-6487] > [CASSANDRA-8011|https://issues.apache.org/jira/browse/CASSANDRA-8011] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8103) Secondary Indices for Static Columns
[ https://issues.apache.org/jira/browse/CASSANDRA-8103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15068519#comment-15068519 ] Taiyuan Zhang commented on CASSANDRA-8103: -- Last progress on this issue seems to be from quite a while ago. If there's no one actively working on this, I'd like to lend a hand here and work on this. > Secondary Indices for Static Columns > > > Key: CASSANDRA-8103 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8103 > Project: Cassandra > Issue Type: New Feature > Components: CQL >Reporter: Ron Cohen >Assignee: Sam Tunnicliffe > Fix For: 3.x > > Attachments: in_progress.patch > > > We should add secondary index support for static columns. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10876) Alter behavior of batch WARN and fail on single partition batches
[ https://issues.apache.org/jira/browse/CASSANDRA-10876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15064053#comment-15064053 ] Taiyuan Zhang commented on CASSANDRA-10876: --- I would like to work on this. Just checking out related issues, in 8825 there suppose to be a discussion around the impact of batch size under different situation, but there wasn't. So did we reach a conclusion that the size of a single partition isn't a problem? > Alter behavior of batch WARN and fail on single partition batches > - > > Key: CASSANDRA-10876 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10876 > Project: Cassandra > Issue Type: Improvement >Reporter: Patrick McFadin >Priority: Minor > > In an attempt to give operator insight into potentially harmful batch usage, > Jiras were created to log WARN or fail on certain batch sizes. This ignores > the single partition batch, which doesn't create the same issues as a > multi-partition batch. > The proposal is to ignore size on single partition batch statements. > Reference: > [CASSANDRA-6487|https://issues.apache.org/jira/browse/CASSANDRA-6487] > [CASSANDRA-8011|https://issues.apache.org/jira/browse/CASSANDRA-8011] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10252) COPY FROM should respect time_format from cqlshrc
[
https://issues.apache.org/jira/browse/CASSANDRA-10252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15064032#comment-15064032
]
Taiyuan Zhang commented on CASSANDRA-10252:
---
Thanks for the notice :)
> COPY FROM should respect time_format from cqlshrc
> -
>
> Key: CASSANDRA-10252
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10252
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
>Reporter: Carl Yeksigian
>Priority: Minor
> Labels: cqlsh, lhf
> Fix For: 2.1.x
>
>
> Currently, {{COPY FROM}} doesn't respect the {{time_format}} property in
> cqlshrc, we only use that for {{COPY TO}}. We should use the same property
> for both to prevent issues like CASSANDRA-8970.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10252) COPY FROM should respect time_format from cqlshrc
[
https://issues.apache.org/jira/browse/CASSANDRA-10252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15064010#comment-15064010
]
Taiyuan Zhang commented on CASSANDRA-10252:
---
I'm half way through this. A couple of thoughts:
1. The current implementation is to use regular expression to match the time
string against ALL possible CQL built-in datetime formats. I think this is very
valuable and should be kept
2. Therefore, my idea of implementing this is, first try to parse using the
current regular expression approach; if fail, then try to parse using
user-specified format, coming either from explicit command or cqlshrc
Another thing I want to be clear about is: in this issue it says fix version:
2.1.x. Does this mean I should do the modification on just the trunk branch, or
just the 2.1.x branch, or all branches?
> COPY FROM should respect time_format from cqlshrc
> -
>
> Key: CASSANDRA-10252
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10252
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
>Reporter: Carl Yeksigian
>Priority: Minor
> Labels: cqlsh, lhf
> Fix For: 2.1.x
>
>
> Currently, {{COPY FROM}} doesn't respect the {{time_format}} property in
> cqlshrc, we only use that for {{COPY TO}}. We should use the same property
> for both to prevent issues like CASSANDRA-8970.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10718) Group pending compactions based on table
[
https://issues.apache.org/jira/browse/CASSANDRA-10718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15052876#comment-15052876
]
Taiyuan Zhang commented on CASSANDRA-10718:
---
Sorry, wasn't aware of the dtest... will remember next time.
> Group pending compactions based on table
>
>
> Key: CASSANDRA-10718
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10718
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Marcus Eriksson
>Assignee: Tushar Agrawal
>Priority: Minor
> Labels: lhf
> Fix For: 3.x
>
> Attachments: 10718-3.x.txt
>
>
> Currently we only give a global number on how many compactions are pending,
> we should group this on a per-table basis, example:
> {code}
> $ nodetool compactionstats
> pending tasks:
> - keyspace1.standard1: 10
> - other_ks.table: 2
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10718) Group pending compactions based on table
[
https://issues.apache.org/jira/browse/CASSANDRA-10718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15052807#comment-15052807
]
Taiyuan Zhang commented on CASSANDRA-10718:
---
Thanks :)
> Group pending compactions based on table
>
>
> Key: CASSANDRA-10718
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10718
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Marcus Eriksson
>Assignee: Tushar Agrawal
>Priority: Minor
> Labels: lhf
> Fix For: 3.x
>
> Attachments: 10718-3.x.txt
>
>
> Currently we only give a global number on how many compactions are pending,
> we should group this on a per-table basis, example:
> {code}
> $ nodetool compactionstats
> pending tasks:
> - keyspace1.standard1: 10
> - other_ks.table: 2
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10718) Group pending compactions based on table
[
https://issues.apache.org/jira/browse/CASSANDRA-10718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15052800#comment-15052800
]
Taiyuan Zhang commented on CASSANDRA-10718:
---
{{tableNameToCountMap}} is a map inside {{resultMap}}. {{resultMap}} is
returned whenever the user reads from {{pendingTasksByTableName}}.
> Group pending compactions based on table
>
>
> Key: CASSANDRA-10718
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10718
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Marcus Eriksson
>Assignee: Tushar Agrawal
>Priority: Minor
> Labels: lhf
> Fix For: 3.x
>
> Attachments: 10718-3.x.txt
>
>
> Currently we only give a global number on how many compactions are pending,
> we should group this on a per-table basis, example:
> {code}
> $ nodetool compactionstats
> pending tasks:
> - keyspace1.standard1: 10
> - other_ks.table: 2
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10718) Group pending compactions based on table
[
https://issues.apache.org/jira/browse/CASSANDRA-10718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Taiyuan Zhang updated CASSANDRA-10718:
--
Attachment: 10718-3.x.txt
I added a patch for this ticket. I followed @Marcus 's advice and implement a
new jmx method that returns a nested map, grouping the number of compaction
tasks by keyspace then by table name.
> Group pending compactions based on table
>
>
> Key: CASSANDRA-10718
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10718
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Marcus Eriksson
>Assignee: Tushar Agrawal
>Priority: Minor
> Labels: lhf
> Fix For: 3.x
>
> Attachments: 10718-3.x.txt
>
>
> Currently we only give a global number on how many compactions are pending,
> we should group this on a per-table basis, example:
> {code}
> $ nodetool compactionstats
> pending tasks:
> - keyspace1.standard1: 10
> - other_ks.table: 2
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
