From fd14512fd2a4e5031ba3d511ba27c113b3087d07 Mon Sep 17 00:00:00 2001 From: Jonathan Ellis Date: Fri, 9 Aug 2013 15:56:07 -0500 Subject: [PATCH 1/2] migrate 1.1 schema_columnfamilies.key_alias column to key_aliases patch by Alex Liu; reviewed by Tyler Hobbs for CASSANDRA-5800 --- CHANGES.txt | 2 + .../org/apache/cassandra/db/SystemTable.java | 38 +++++++++++++++++++ 2 files changed, 40 insertions(+) diff --git a/CHANGES.txt b/CHANGES.txt index f8c472c3ef..7630084644 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -1,4 +1,6 @@ 1.2.9 + * migrate 1.1 schema_columnfamilies.key_alias column to key_aliases + (CASSANDRA-5800) * add --migrate option to sstableupgrade and sstablescrub (CASSANDRA-5831) * fix bulk-loading compressed sstables (CASSANDRA-5820) * (Hadoop) fix quoting in CqlPagingRecordReader and CqlRecordWriter diff --git a/src/java/org/apache/cassandra/db/SystemTable.java b/src/java/org/apache/cassandra/db/SystemTable.java index 318b34d3cf..32f5fe054e 100644 --- a/src/java/org/apache/cassandra/db/SystemTable.java +++ b/src/java/org/apache/cassandra/db/SystemTable.java @@ -180,6 +180,44 @@ public class SystemTable logger.info("Possible old-format hints found. Truncating"); oldHintsCfs.truncate(); } + + migrateKeyAliases(); + } + + + /** + * 1.1 used a key_alias column; 1.2 changed that to key_aliases as part of CQL3 + */ + private static void migrateKeyAliases() + { + for (UntypedResultSet.Row row : processInternal("SELECT keyspace_name, columnfamily_name, key_aliases, key_alias FROM system.schema_columnfamilies")) + { + String key_alias = null; + String key_aliases = null; + try + { + key_alias = row.getString("key_alias"); + } + catch (NullPointerException e) + { + // column value is null + } + try + { + key_aliases = row.getString("key_aliases"); + } + catch (NullPointerException e) + { + // column value is null + } + if (key_alias != null && key_aliases == null) + { + String keyspace = row.getString("keyspace_name"); + String columnfamily = row.getString("columnfamily_name"); + processInternal(String.format("UPDATE system.schema_columnfamilies set key_aliases='[\"%s\"]' , key_alias = null where keyspace_name='%s' and columnfamily_name='%s'", + key_alias, keyspace, columnfamily)); + } + } } public static void saveTruncationRecord(ColumnFamilyStore cfs, long truncatedAt, ReplayPosition position) From 2a8379372e6cbcd2fa3008b203c70f57ad29f392 Mon Sep 17 00:00:00 2001 From: Aleksey Yeschenko Date: Sat, 10 Aug 2013 02:41:58 +0200 Subject: [PATCH 2/2] Correct timestamp formatting in CQL3 doc --- doc/cql3/CQL.textile | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/doc/cql3/CQL.textile b/doc/cql3/CQL.textile index 532d341321..22248efb8b 100644 --- a/doc/cql3/CQL.textile +++ b/doc/cql3/CQL.textile @@ -611,8 +611,8 @@ SELECT name, occupation FROM users WHERE userid IN (199, 200, 207); SELECT time, value FROM events WHERE event_type = 'myEvent' - AND time > 2011-02-03 - AND time <= 2012-01-01 + AND time > '2011-02-03' + AND time <= '2012-01-01' SELECT COUNT(*) FROM users; p. @@ -646,13 +646,13 @@ CREATE TABLE posts ( The following query is allowed: bc(sample). -SELECT entry_title, content FROM posts WHERE userid='john doe' AND blog_title='John's Blog' AND posted_at >= 2012-01-01 AND posted_at < 2012-01-31 +SELECT entry_title, content FROM posts WHERE userid='john doe' AND blog_title='John's Blog' AND posted_at >= '2012-01-01' AND posted_at < '2012-01-31' But the following one is not, as it does not select a contiguous set of rows (and we suppose no secondary indexes are set): bc(sample). // Needs a blog_title to be set to select ranges of posted_at -SELECT entry_title, content FROM posts WHERE userid='john doe' AND posted_at >= 2012-01-01 AND posted_at < 2012-01-31 +SELECT entry_title, content FROM posts WHERE userid='john doe' AND posted_at >= '2012-01-01' AND posted_at < '2012-01-31' When specifying relations, the @TOKEN@ function can be used on the @PARTITION KEY@ column to query. In that case, rows will be selected based on the token of their @PARTITION_KEY@ rather than on the value. Note that the token of a key depends on the partitioner in use, and that in particular the RandomPartitioner won't yeld a meaningful order. Also note that ordering partitioners always order token values by bytes (so even if the partition key is of type int, @token(-1) > token(0)@ in particular). Example: