You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Cathy Daw (Created) (JIRA)" <ji...@apache.org> on 2011/11/18 06:35:51 UTC
[jira] [Created] (CASSANDRA-3505) tombstone appears after truncate
tombstone appears after truncate
--------------------------------
Key: CASSANDRA-3505
URL: https://issues.apache.org/jira/browse/CASSANDRA-3505
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 1.0.3
Reporter: Cathy Daw
Assignee: T Jake Luciani
This bug is regarding the select after the 'truncate'. In 1.0.1 no rows would ever be returned, but now we are seeing a tombstone when querying for user1. Jake mentioned this may be related to CASSANDRA-2855.
{code}
cqlsh> CREATE KEYSPACE ks1 with
... strategy_class =
... 'org.apache.cassandra.locator.SimpleStrategy'
... and strategy_options:replication_factor=1;
cqlsh> use ks1;
cqlsh:ks1>
cqlsh:ks1> CREATE COLUMNFAMILY users (
... KEY varchar PRIMARY KEY, password varchar, gender varchar,
... session_token varchar, state varchar, birth_year bigint);
cqlsh:ks1> INSERT INTO users (KEY, password) VALUES ('user1', 'ch@ngem3a');
cqlsh:ks1> UPDATE users SET gender = 'm', birth_year = '1980' WHERE KEY = 'user1';
cqlsh:ks1> SELECT * FROM users WHERE key='user1';
KEY | birth_year | gender | password |
user1 | 1980 | m | ch@ngem3a |
cqlsh:ks1> TRUNCATE users;
// Expected, no rows returned
cqlsh:ks1> SELECT * FROM users WHERE key='user1';
KEY |
user1 |
// Expected, no rows returned
cqlsh:ks1> SELECT * FROM users;
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3505) tombstone appears after
truncate
Posted by "Brandon Williams (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-3505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13152694#comment-13152694 ]
Brandon Williams commented on CASSANDRA-3505:
---------------------------------------------
CASSANDRA-2855 only affects hadoop.
> tombstone appears after truncate
> --------------------------------
>
> Key: CASSANDRA-3505
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3505
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Affects Versions: 1.0.3
> Reporter: Cathy Daw
> Assignee: T Jake Luciani
>
> This bug is regarding the select after the 'truncate'. In 1.0.1 no rows would ever be returned, but now we are seeing a tombstone when querying for user1. Jake mentioned this may be related to CASSANDRA-2855.
> {code}
> cqlsh> CREATE KEYSPACE ks1 with
> ... strategy_class =
> ... 'org.apache.cassandra.locator.SimpleStrategy'
> ... and strategy_options:replication_factor=1;
>
> cqlsh> use ks1;
> cqlsh:ks1>
> cqlsh:ks1> CREATE COLUMNFAMILY users (
> ... KEY varchar PRIMARY KEY, password varchar, gender varchar,
> ... session_token varchar, state varchar, birth_year bigint);
> cqlsh:ks1> INSERT INTO users (KEY, password) VALUES ('user1', 'ch@ngem3a');
> cqlsh:ks1> UPDATE users SET gender = 'm', birth_year = '1980' WHERE KEY = 'user1';
> cqlsh:ks1> SELECT * FROM users WHERE key='user1';
> KEY | birth_year | gender | password |
> user1 | 1980 | m | ch@ngem3a |
> cqlsh:ks1> TRUNCATE users;
> // Expected, no rows returned
> cqlsh:ks1> SELECT * FROM users WHERE key='user1';
> KEY |
> user1 |
> // Expected, no rows returned
> cqlsh:ks1> SELECT * FROM users;
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CASSANDRA-3505) tombstone appears after truncate
Posted by "Jonathan Ellis (Assigned) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-3505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jonathan Ellis reassigned CASSANDRA-3505:
-----------------------------------------
Assignee: Jonathan Ellis (was: Yuki Morishita)
> tombstone appears after truncate
> --------------------------------
>
> Key: CASSANDRA-3505
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3505
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Affects Versions: 1.0.3
> Reporter: Cathy Daw
> Assignee: Jonathan Ellis
> Fix For: 1.0.4
>
>
> This bug is regarding the select after the 'truncate'. In 1.0.1 no rows would ever be returned, but now we are seeing a tombstone when querying for user1. Jake mentioned this may be related to CASSANDRA-2855.
> {code}
> cqlsh> CREATE KEYSPACE ks1 with
> ... strategy_class =
> ... 'org.apache.cassandra.locator.SimpleStrategy'
> ... and strategy_options:replication_factor=1;
>
> cqlsh> use ks1;
> cqlsh:ks1>
> cqlsh:ks1> CREATE COLUMNFAMILY users (
> ... KEY varchar PRIMARY KEY, password varchar, gender varchar,
> ... session_token varchar, state varchar, birth_year bigint);
> cqlsh:ks1> INSERT INTO users (KEY, password) VALUES ('user1', 'ch@ngem3a');
> cqlsh:ks1> UPDATE users SET gender = 'm', birth_year = '1980' WHERE KEY = 'user1';
> cqlsh:ks1> SELECT * FROM users WHERE key='user1';
> KEY | birth_year | gender | password |
> user1 | 1980 | m | ch@ngem3a |
> cqlsh:ks1> TRUNCATE users;
> // Expected, no rows returned
> cqlsh:ks1> SELECT * FROM users WHERE key='user1';
> KEY |
> user1 |
> // Expected, no rows returned
> cqlsh:ks1> SELECT * FROM users;
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3505) tombstone appears after
truncate
Posted by "Cathy Daw (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-3505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13156428#comment-13156428 ]
Cathy Daw commented on CASSANDRA-3505:
--------------------------------------
Not sure if you guys are aware, but this behavior still exists in 1.0.3.
> tombstone appears after truncate
> --------------------------------
>
> Key: CASSANDRA-3505
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3505
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Affects Versions: 1.0.3
> Reporter: Cathy Daw
> Assignee: Jonathan Ellis
> Priority: Minor
>
> This bug is regarding the select after the 'truncate'. In 1.0.1 no rows would ever be returned, but now we are seeing a tombstone when querying for user1. Jake mentioned this may be related to CASSANDRA-2855.
> {code}
> cqlsh> CREATE KEYSPACE ks1 with
> ... strategy_class =
> ... 'org.apache.cassandra.locator.SimpleStrategy'
> ... and strategy_options:replication_factor=1;
>
> cqlsh> use ks1;
> cqlsh:ks1>
> cqlsh:ks1> CREATE COLUMNFAMILY users (
> ... KEY varchar PRIMARY KEY, password varchar, gender varchar,
> ... session_token varchar, state varchar, birth_year bigint);
> cqlsh:ks1> INSERT INTO users (KEY, password) VALUES ('user1', 'ch@ngem3a');
> cqlsh:ks1> UPDATE users SET gender = 'm', birth_year = '1980' WHERE KEY = 'user1';
> cqlsh:ks1> SELECT * FROM users WHERE key='user1';
> KEY | birth_year | gender | password |
> user1 | 1980 | m | ch@ngem3a |
> cqlsh:ks1> TRUNCATE users;
> // Expected, no rows returned
> cqlsh:ks1> SELECT * FROM users WHERE key='user1';
> KEY |
> user1 |
> // Expected, no rows returned
> cqlsh:ks1> SELECT * FROM users;
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3505) tombstone appears after
truncate
Posted by "Jonathan Ellis (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-3505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13155336#comment-13155336 ]
Jonathan Ellis commented on CASSANDRA-3505:
-------------------------------------------
Thanks for tracking that down, Yuki. I'll put together a patch.
> tombstone appears after truncate
> --------------------------------
>
> Key: CASSANDRA-3505
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3505
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Affects Versions: 1.0.3
> Reporter: Cathy Daw
> Assignee: Jonathan Ellis
> Fix For: 1.0.4
>
>
> This bug is regarding the select after the 'truncate'. In 1.0.1 no rows would ever be returned, but now we are seeing a tombstone when querying for user1. Jake mentioned this may be related to CASSANDRA-2855.
> {code}
> cqlsh> CREATE KEYSPACE ks1 with
> ... strategy_class =
> ... 'org.apache.cassandra.locator.SimpleStrategy'
> ... and strategy_options:replication_factor=1;
>
> cqlsh> use ks1;
> cqlsh:ks1>
> cqlsh:ks1> CREATE COLUMNFAMILY users (
> ... KEY varchar PRIMARY KEY, password varchar, gender varchar,
> ... session_token varchar, state varchar, birth_year bigint);
> cqlsh:ks1> INSERT INTO users (KEY, password) VALUES ('user1', 'ch@ngem3a');
> cqlsh:ks1> UPDATE users SET gender = 'm', birth_year = '1980' WHERE KEY = 'user1';
> cqlsh:ks1> SELECT * FROM users WHERE key='user1';
> KEY | birth_year | gender | password |
> user1 | 1980 | m | ch@ngem3a |
> cqlsh:ks1> TRUNCATE users;
> // Expected, no rows returned
> cqlsh:ks1> SELECT * FROM users WHERE key='user1';
> KEY |
> user1 |
> // Expected, no rows returned
> cqlsh:ks1> SELECT * FROM users;
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3505) tombstone appears after
truncate
Posted by "Jonathan Ellis (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-3505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13152681#comment-13152681 ]
Jonathan Ellis commented on CASSANDRA-3505:
-------------------------------------------
Weird, since truncate doesn't create tombstones -- it blows the data away entirely.
> tombstone appears after truncate
> --------------------------------
>
> Key: CASSANDRA-3505
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3505
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Affects Versions: 1.0.3
> Reporter: Cathy Daw
> Assignee: T Jake Luciani
>
> This bug is regarding the select after the 'truncate'. In 1.0.1 no rows would ever be returned, but now we are seeing a tombstone when querying for user1. Jake mentioned this may be related to CASSANDRA-2855.
> {code}
> cqlsh> CREATE KEYSPACE ks1 with
> ... strategy_class =
> ... 'org.apache.cassandra.locator.SimpleStrategy'
> ... and strategy_options:replication_factor=1;
>
> cqlsh> use ks1;
> cqlsh:ks1>
> cqlsh:ks1> CREATE COLUMNFAMILY users (
> ... KEY varchar PRIMARY KEY, password varchar, gender varchar,
> ... session_token varchar, state varchar, birth_year bigint);
> cqlsh:ks1> INSERT INTO users (KEY, password) VALUES ('user1', 'ch@ngem3a');
> cqlsh:ks1> UPDATE users SET gender = 'm', birth_year = '1980' WHERE KEY = 'user1';
> cqlsh:ks1> SELECT * FROM users WHERE key='user1';
> KEY | birth_year | gender | password |
> user1 | 1980 | m | ch@ngem3a |
> cqlsh:ks1> TRUNCATE users;
> // Expected, no rows returned
> cqlsh:ks1> SELECT * FROM users WHERE key='user1';
> KEY |
> user1 |
> // Expected, no rows returned
> cqlsh:ks1> SELECT * FROM users;
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3505) tombstone appears after
truncate
Posted by "Yuki Morishita (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-3505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13155300#comment-13155300 ]
Yuki Morishita commented on CASSANDRA-3505:
-------------------------------------------
This change in behavior comes from CASSANDRA-3424, which is fixed in 1.0.3.
See Jonathan's commented in above ticket(https://issues.apache.org/jira/browse/CASSANDRA-3424?focusedCommentId=13145954&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13145954) for current behavior.
> tombstone appears after truncate
> --------------------------------
>
> Key: CASSANDRA-3505
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3505
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Affects Versions: 1.0.3
> Reporter: Cathy Daw
> Assignee: Yuki Morishita
> Fix For: 1.0.4
>
>
> This bug is regarding the select after the 'truncate'. In 1.0.1 no rows would ever be returned, but now we are seeing a tombstone when querying for user1. Jake mentioned this may be related to CASSANDRA-2855.
> {code}
> cqlsh> CREATE KEYSPACE ks1 with
> ... strategy_class =
> ... 'org.apache.cassandra.locator.SimpleStrategy'
> ... and strategy_options:replication_factor=1;
>
> cqlsh> use ks1;
> cqlsh:ks1>
> cqlsh:ks1> CREATE COLUMNFAMILY users (
> ... KEY varchar PRIMARY KEY, password varchar, gender varchar,
> ... session_token varchar, state varchar, birth_year bigint);
> cqlsh:ks1> INSERT INTO users (KEY, password) VALUES ('user1', 'ch@ngem3a');
> cqlsh:ks1> UPDATE users SET gender = 'm', birth_year = '1980' WHERE KEY = 'user1';
> cqlsh:ks1> SELECT * FROM users WHERE key='user1';
> KEY | birth_year | gender | password |
> user1 | 1980 | m | ch@ngem3a |
> cqlsh:ks1> TRUNCATE users;
> // Expected, no rows returned
> cqlsh:ks1> SELECT * FROM users WHERE key='user1';
> KEY |
> user1 |
> // Expected, no rows returned
> cqlsh:ks1> SELECT * FROM users;
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CASSANDRA-3505) Explicitly requested keys will
always be present in resultset
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-3505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jonathan Ellis resolved CASSANDRA-3505.
---------------------------------------
Resolution: Duplicate
I don't think there's a good way to fix this in CQL2.
> Explicitly requested keys will always be present in resultset
> -------------------------------------------------------------
>
> Key: CASSANDRA-3505
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3505
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Affects Versions: 1.0.3
> Reporter: Cathy Daw
> Assignee: Jonathan Ellis
> Priority: Minor
>
> This bug is regarding the select after the 'truncate'. In 1.0.1 no rows would ever be returned, but now we are seeing a tombstone when querying for user1. Jake mentioned this may be related to CASSANDRA-2855.
> {code}
> cqlsh> CREATE KEYSPACE ks1 with
> ... strategy_class =
> ... 'org.apache.cassandra.locator.SimpleStrategy'
> ... and strategy_options:replication_factor=1;
>
> cqlsh> use ks1;
> cqlsh:ks1>
> cqlsh:ks1> CREATE COLUMNFAMILY users (
> ... KEY varchar PRIMARY KEY, password varchar, gender varchar,
> ... session_token varchar, state varchar, birth_year bigint);
> cqlsh:ks1> INSERT INTO users (KEY, password) VALUES ('user1', 'ch@ngem3a');
> cqlsh:ks1> UPDATE users SET gender = 'm', birth_year = '1980' WHERE KEY = 'user1';
> cqlsh:ks1> SELECT * FROM users WHERE key='user1';
> KEY | birth_year | gender | password |
> user1 | 1980 | m | ch@ngem3a |
> cqlsh:ks1> TRUNCATE users;
> // Expected, no rows returned
> cqlsh:ks1> SELECT * FROM users WHERE key='user1';
> KEY |
> user1 |
> // Expected, no rows returned
> cqlsh:ks1> SELECT * FROM users;
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3505) Explicitly requested keys will
always be present in resultset
Posted by "Shotaro Kamio (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-3505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13169150#comment-13169150 ]
Shotaro Kamio commented on CASSANDRA-3505:
------------------------------------------
This issue causes following python-cql incorrect behavior (rowcount is incorrect).
http://code.google.com/a/apache-extras.org/p/cassandra-dbapi2/issues/detail?id=10
> Explicitly requested keys will always be present in resultset
> -------------------------------------------------------------
>
> Key: CASSANDRA-3505
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3505
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Affects Versions: 1.0.3
> Reporter: Cathy Daw
> Assignee: Jonathan Ellis
> Priority: Minor
>
> This bug is regarding the select after the 'truncate'. In 1.0.1 no rows would ever be returned, but now we are seeing a tombstone when querying for user1. Jake mentioned this may be related to CASSANDRA-2855.
> {code}
> cqlsh> CREATE KEYSPACE ks1 with
> ... strategy_class =
> ... 'org.apache.cassandra.locator.SimpleStrategy'
> ... and strategy_options:replication_factor=1;
>
> cqlsh> use ks1;
> cqlsh:ks1>
> cqlsh:ks1> CREATE COLUMNFAMILY users (
> ... KEY varchar PRIMARY KEY, password varchar, gender varchar,
> ... session_token varchar, state varchar, birth_year bigint);
> cqlsh:ks1> INSERT INTO users (KEY, password) VALUES ('user1', 'ch@ngem3a');
> cqlsh:ks1> UPDATE users SET gender = 'm', birth_year = '1980' WHERE KEY = 'user1';
> cqlsh:ks1> SELECT * FROM users WHERE key='user1';
> KEY | birth_year | gender | password |
> user1 | 1980 | m | ch@ngem3a |
> cqlsh:ks1> TRUNCATE users;
> // Expected, no rows returned
> cqlsh:ks1> SELECT * FROM users WHERE key='user1';
> KEY |
> user1 |
> // Expected, no rows returned
> cqlsh:ks1> SELECT * FROM users;
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-3505) tombstone appears after truncate
Posted by "Jonathan Ellis (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-3505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jonathan Ellis updated CASSANDRA-3505:
--------------------------------------
Priority: Minor (was: Major)
Fix Version/s: (was: 1.0.4)
Hmm. I don't think there's a quick fix for this. StorageProxy/ReadVerbHandler doesn't distinguish between "row exists but not the columns you asked for" (should include empty row in the resultset) and "row doesn't exist at all" (should not).
> tombstone appears after truncate
> --------------------------------
>
> Key: CASSANDRA-3505
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3505
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Affects Versions: 1.0.3
> Reporter: Cathy Daw
> Assignee: Jonathan Ellis
> Priority: Minor
>
> This bug is regarding the select after the 'truncate'. In 1.0.1 no rows would ever be returned, but now we are seeing a tombstone when querying for user1. Jake mentioned this may be related to CASSANDRA-2855.
> {code}
> cqlsh> CREATE KEYSPACE ks1 with
> ... strategy_class =
> ... 'org.apache.cassandra.locator.SimpleStrategy'
> ... and strategy_options:replication_factor=1;
>
> cqlsh> use ks1;
> cqlsh:ks1>
> cqlsh:ks1> CREATE COLUMNFAMILY users (
> ... KEY varchar PRIMARY KEY, password varchar, gender varchar,
> ... session_token varchar, state varchar, birth_year bigint);
> cqlsh:ks1> INSERT INTO users (KEY, password) VALUES ('user1', 'ch@ngem3a');
> cqlsh:ks1> UPDATE users SET gender = 'm', birth_year = '1980' WHERE KEY = 'user1';
> cqlsh:ks1> SELECT * FROM users WHERE key='user1';
> KEY | birth_year | gender | password |
> user1 | 1980 | m | ch@ngem3a |
> cqlsh:ks1> TRUNCATE users;
> // Expected, no rows returned
> cqlsh:ks1> SELECT * FROM users WHERE key='user1';
> KEY |
> user1 |
> // Expected, no rows returned
> cqlsh:ks1> SELECT * FROM users;
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3505) Explicitly requested keys will
always be present in resultset
Posted by "Eric Evans (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-3505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13169712#comment-13169712 ]
Eric Evans commented on CASSANDRA-3505:
---------------------------------------
This was introduced by https://issues.apache.org/jira/browse/CASSANDRA-3424
> Explicitly requested keys will always be present in resultset
> -------------------------------------------------------------
>
> Key: CASSANDRA-3505
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3505
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Affects Versions: 1.0.3
> Reporter: Cathy Daw
> Assignee: Jonathan Ellis
> Priority: Minor
>
> This bug is regarding the select after the 'truncate'. In 1.0.1 no rows would ever be returned, but now we are seeing a tombstone when querying for user1. Jake mentioned this may be related to CASSANDRA-2855.
> {code}
> cqlsh> CREATE KEYSPACE ks1 with
> ... strategy_class =
> ... 'org.apache.cassandra.locator.SimpleStrategy'
> ... and strategy_options:replication_factor=1;
>
> cqlsh> use ks1;
> cqlsh:ks1>
> cqlsh:ks1> CREATE COLUMNFAMILY users (
> ... KEY varchar PRIMARY KEY, password varchar, gender varchar,
> ... session_token varchar, state varchar, birth_year bigint);
> cqlsh:ks1> INSERT INTO users (KEY, password) VALUES ('user1', 'ch@ngem3a');
> cqlsh:ks1> UPDATE users SET gender = 'm', birth_year = '1980' WHERE KEY = 'user1';
> cqlsh:ks1> SELECT * FROM users WHERE key='user1';
> KEY | birth_year | gender | password |
> user1 | 1980 | m | ch@ngem3a |
> cqlsh:ks1> TRUNCATE users;
> // Expected, no rows returned
> cqlsh:ks1> SELECT * FROM users WHERE key='user1';
> KEY |
> user1 |
> // Expected, no rows returned
> cqlsh:ks1> SELECT * FROM users;
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-3505) Explicitly requested keys will
always be present in resultset
Posted by "Jonathan Ellis (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-3505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jonathan Ellis updated CASSANDRA-3505:
--------------------------------------
Summary: Explicitly requested keys will always be present in resultset (was: tombstone appears after truncate)
> Explicitly requested keys will always be present in resultset
> -------------------------------------------------------------
>
> Key: CASSANDRA-3505
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3505
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Affects Versions: 1.0.3
> Reporter: Cathy Daw
> Assignee: Jonathan Ellis
> Priority: Minor
>
> This bug is regarding the select after the 'truncate'. In 1.0.1 no rows would ever be returned, but now we are seeing a tombstone when querying for user1. Jake mentioned this may be related to CASSANDRA-2855.
> {code}
> cqlsh> CREATE KEYSPACE ks1 with
> ... strategy_class =
> ... 'org.apache.cassandra.locator.SimpleStrategy'
> ... and strategy_options:replication_factor=1;
>
> cqlsh> use ks1;
> cqlsh:ks1>
> cqlsh:ks1> CREATE COLUMNFAMILY users (
> ... KEY varchar PRIMARY KEY, password varchar, gender varchar,
> ... session_token varchar, state varchar, birth_year bigint);
> cqlsh:ks1> INSERT INTO users (KEY, password) VALUES ('user1', 'ch@ngem3a');
> cqlsh:ks1> UPDATE users SET gender = 'm', birth_year = '1980' WHERE KEY = 'user1';
> cqlsh:ks1> SELECT * FROM users WHERE key='user1';
> KEY | birth_year | gender | password |
> user1 | 1980 | m | ch@ngem3a |
> cqlsh:ks1> TRUNCATE users;
> // Expected, no rows returned
> cqlsh:ks1> SELECT * FROM users WHERE key='user1';
> KEY |
> user1 |
> // Expected, no rows returned
> cqlsh:ks1> SELECT * FROM users;
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-3505) tombstone appears after truncate
Posted by "Jonathan Ellis (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-3505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jonathan Ellis updated CASSANDRA-3505:
--------------------------------------
Reviewer: jbellis
Fix Version/s: 1.0.4
Assignee: Yuki Morishita (was: T Jake Luciani)
> tombstone appears after truncate
> --------------------------------
>
> Key: CASSANDRA-3505
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3505
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Affects Versions: 1.0.3
> Reporter: Cathy Daw
> Assignee: Yuki Morishita
> Fix For: 1.0.4
>
>
> This bug is regarding the select after the 'truncate'. In 1.0.1 no rows would ever be returned, but now we are seeing a tombstone when querying for user1. Jake mentioned this may be related to CASSANDRA-2855.
> {code}
> cqlsh> CREATE KEYSPACE ks1 with
> ... strategy_class =
> ... 'org.apache.cassandra.locator.SimpleStrategy'
> ... and strategy_options:replication_factor=1;
>
> cqlsh> use ks1;
> cqlsh:ks1>
> cqlsh:ks1> CREATE COLUMNFAMILY users (
> ... KEY varchar PRIMARY KEY, password varchar, gender varchar,
> ... session_token varchar, state varchar, birth_year bigint);
> cqlsh:ks1> INSERT INTO users (KEY, password) VALUES ('user1', 'ch@ngem3a');
> cqlsh:ks1> UPDATE users SET gender = 'm', birth_year = '1980' WHERE KEY = 'user1';
> cqlsh:ks1> SELECT * FROM users WHERE key='user1';
> KEY | birth_year | gender | password |
> user1 | 1980 | m | ch@ngem3a |
> cqlsh:ks1> TRUNCATE users;
> // Expected, no rows returned
> cqlsh:ks1> SELECT * FROM users WHERE key='user1';
> KEY |
> user1 |
> // Expected, no rows returned
> cqlsh:ks1> SELECT * FROM users;
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira