cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From slebre...@apache.org
Subject [2/3] git commit: Merge branch 'cassandra-2.0' into cassandra-2.1.0
Date Mon, 25 Aug 2014 14:42:50 GMT
Merge branch 'cassandra-2.0' into cassandra-2.1.0

Conflicts:
	CHANGES.txt
	src/java/org/apache/cassandra/cql3/statements/SelectStatement.java


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/889f3ac5
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/889f3ac5
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/889f3ac5

Branch: refs/heads/cassandra-2.1
Commit: 889f3ac5548b89c17bade2f39781067db95a0c27
Parents: 63c21a3 2015072
Author: Sylvain Lebresne <sylvain@datastax.com>
Authored: Mon Aug 25 16:41:08 2014 +0200
Committer: Sylvain Lebresne <sylvain@datastax.com>
Committed: Mon Aug 25 16:41:08 2014 +0200

----------------------------------------------------------------------
 CHANGES.txt                                                     | 2 ++
 .../org/apache/cassandra/cql3/statements/SelectStatement.java   | 5 +++++
 2 files changed, 7 insertions(+)
----------------------------------------------------------------------


http://git-wip-us.apache.org/repos/asf/cassandra/blob/889f3ac5/CHANGES.txt
----------------------------------------------------------------------
diff --cc CHANGES.txt
index 15e41da,e716cb5..80747dc
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -1,12 -1,9 +1,14 @@@
 -2.0.11:
 +2.1.0
 + * Correctly remove tmplink files (CASSANDRA-7803)
 + * (cqlsh) Fix column name formatting for functions, CAS operations,
 +   and UDT field selections (CASSANDRA-7806)
 + * (cqlsh) Fix COPY FROM handling of null/empty primary key
 +   values (CASSANDRA-7792)
 + * Fix ordering of static cells (CASSANDRA-7763)
 +Merged from 2.0:
+  * Always reject inequality on the partition key without token()
+    (CASSANDRA-7722)
   * Always send Paxos commit to all replicas (CASSANDRA-7479)
 -
 -2.0.10
   * Don't send schema change responses and events for no-op DDL
     statements (CASSANDRA-7600)
   * (Hadoop) fix cluster initialisation for a split fetching (CASSANDRA-7774)

http://git-wip-us.apache.org/repos/asf/cassandra/blob/889f3ac5/src/java/org/apache/cassandra/cql3/statements/SelectStatement.java
----------------------------------------------------------------------
diff --cc src/java/org/apache/cassandra/cql3/statements/SelectStatement.java
index e4ef0a8,a360d49..20b5f57
--- a/src/java/org/apache/cassandra/cql3/statements/SelectStatement.java
+++ b/src/java/org/apache/cassandra/cql3/statements/SelectStatement.java
@@@ -1675,38 -1704,23 +1675,43 @@@ public class SelectStatement implement
                  case GTE:
                  case LT:
                  case LTE:
 +                    {
 +                        if (existingRestriction == null)
 +                            existingRestriction = new SingleColumnRestriction.Slice(newRel.onToken);
 +                        else if (!existingRestriction.isSlice())
 +                            throw new InvalidRequestException(String.format("Column \"%s\"
cannot be restricted by both an equality and an inequality relation", def.name));
 +                        else if (existingRestriction.isMultiColumn())
 +                            throw new InvalidRequestException(String.format("Column \"%s\"
cannot be restricted by both a tuple notation inequality and a single column inequality (%s)",
def.name, newRel));
++                        else if (existingRestriction.isOnToken() != newRel.onToken)
++                            // For partition keys, we shouldn't have slice restrictions
without token(). And while this is rejected later by
++                            // processPartitionKeysRestrictions, we shouldn't update the
existing restriction by the new one if the old one was using token()
++                            // and the new one isn't since that would bypass that later
test.
++                            throw new InvalidRequestException("Only EQ and IN relation are
supported on the partition key (unless you use the token() function)");
 +
 +                        Term t = newRel.getValue().prepare(keyspace(), receiver);
 +                        t.collectMarkerSpecification(boundNames);
 +                        ((SingleColumnRestriction.Slice)existingRestriction).setBound(def.name,
newRel.operator(), t);
 +                    }
 +                    break;
 +                case CONTAINS_KEY:
 +                    if (!(receiver.type instanceof MapType))
 +                        throw new InvalidRequestException(String.format("Cannot use CONTAINS_KEY
on non-map column %s", def.name));
 +                    // Fallthrough on purpose
 +                case CONTAINS:
                  {
 +                    if (!receiver.type.isCollection())
 +                        throw new InvalidRequestException(String.format("Cannot use %s relation
on non collection column %s", newRel.operator(), def.name));
 +
                      if (existingRestriction == null)
 -                        existingRestriction = new SingleColumnRestriction.Slice(newRel.onToken);
 -                    else if (!existingRestriction.isSlice())
 -                        throw new InvalidRequestException(String.format("Column \"%s\" cannot
be restricted by both an equality and an inequality relation", name));
 -                    else if (existingRestriction.isOnToken() != newRel.onToken)
 -                        // For partition keys, we shouldn't have slice restrictions without
token(). And while this is rejected later by
 -                        // processPartitionKeysRestrictions, we shouldn't update the existing
restriction by the new one if the old one was using token()
 -                        // and the new one isn't since that would bypass that later test.
 -                        throw new InvalidRequestException("Only EQ and IN relation are supported
on the partition key (unless you use the token() function)");
 -                    else if (existingRestriction.isMultiColumn())
 -                        throw new InvalidRequestException(String.format("Column \"%s\" cannot
be restricted by both a tuple notation inequality and a single column inequality (%s)", name,
newRel));
 -                    Term t = newRel.getValue().prepare(receiver);
 +                        existingRestriction = new SingleColumnRestriction.Contains();
 +                    else if (!existingRestriction.isContains())
 +                        throw new InvalidRequestException(String.format("Collection column
%s can only be restricted by CONTAINS or CONTAINS KEY", def.name));
 +                    boolean isKey = newRel.operator() == Relation.Type.CONTAINS_KEY;
 +                    receiver = makeCollectionReceiver(receiver, isKey);
 +                    Term t = newRel.getValue().prepare(keyspace(), receiver);
                      t.collectMarkerSpecification(boundNames);
 -                    ((SingleColumnRestriction.Slice)existingRestriction).setBound(newRel.operator(),
t);
 +                    ((SingleColumnRestriction.Contains)existingRestriction).add(t, isKey);
                  }
 -                break;
              }
              return existingRestriction;
          }


Mime
View raw message