[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] [Comment Edited] (CASSANDRA-10707) Add support for Group By to Select statement
[
https://issues.apache.org/jira/browse/CASSANDRA-10707?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15076378#comment-15076378
]
Benjamin Lerer edited comment on CASSANDRA-10707 at 1/1/16 9:36 PM:
Both will be supported.
What will not be supported is a {{group by}} clause where only a part of the
partition key will be specified. For example, if a table has a primary key like
{{PRIMARY KEY((partitionKey1, partitionKey2) clustering1, clustering2)}}, the
following query will not be supported:
{{SELECT partitionKey1, MAX(value) FROM myTable GROUP BY partitionKey1}}
As for the aggregates, the grouping will be performed on the coordinator node.
By consequence, if the driver use the Token aware policy, a query containing a
partition key predicate will be more efficient as the aggregates will be built
on the node where the data are located.
>From the syntax point of view, the queries:
{{SELECT partitionKey, clusteringColumn1, Max(value) FROM myTable WHERE
partitionKey=5 GROUP BY partitionKey, clusteringColumn1;}}
and {{SELECT partitionKey, clusteringColumn1, Max(value) FROM myTable WHERE
partitionKey=5 GROUP BY clusteringColumn1;}} will be both supported due to the
fact that the {{partitionKey}} column is restricted by an {{=}} operator.
was (Author: blerer):
Both will be supported.
What will not be supported is a {{group by}} clause were only a part of the
partition key will be specified. For example, if a table has a primary key like
{{PRIMARY KEY((partitionKey1, partitionKey2) clustering1, clustering2)}}, the
following query will not be supported:
{{SELECT partitionKey1, MAX(value) FROM myTable GROUP BY partitionKey1}}
As for the aggregates, the grouping will be performed on the coordinator node.
By consequence, if the driver use the Token aware policy, a query containing a
partition key predicate will be more efficient as the aggregates will be built
on the node where the data are located.
>From the syntax point of view, the queries:
{{SELECT partitionKey, clusteringColumn1, Max(value) FROM myTable WHERE
partitionKey=5 GROUP BY partitionKey, clusteringColumn1;}}
and {{SELECT partitionKey, clusteringColumn1, Max(value) FROM myTable WHERE
partitionKey=5 GROUP BY clusteringColumn1;}} will be both supported due to the
fact that the {{partitionKey}} column is restricted by an {{=}} operator.
> Add support for Group By to Select statement
>
>
> Key: CASSANDRA-10707
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10707
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>
> Now that Cassandra support aggregate functions, it makes sense to support
> {{GROUP BY}} on the {{SELECT}} statements.
> It should be possible to group either at the partition level or at the
> clustering column level.
> {code}
> SELECT partitionKey, max(value) FROM myTable GROUP BY partitionKey;
> SELECT partitionKey, clustering0, clustering1, max(value) FROM myTable GROUP
> BY partitionKey, clustering0, clustering1;
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10707) Add support for Group By to Select statement
[
https://issues.apache.org/jira/browse/CASSANDRA-10707?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15076378#comment-15076378
]
Benjamin Lerer commented on CASSANDRA-10707:
Both will be supported.
What will not be supported is a {{group by}} clause were only a part of the
partition key will be specified. For example, if a table has a primary key like
{{PRIMARY KEY((partitionKey1, partitionKey2) clustering1, clustering2)}}, the
following query will not be supported:
{{SELECT partitionKey1, MAX(value) FROM myTable GROUP BY partitionKey1}}
As for the aggregates, the grouping will be performed on the coordinator node.
By consequence, if the driver use the Token aware policy, a query containing a
partition key predicate will be more efficient as the aggregates will be built
on the node where the data are located.
>From the syntax point of view, the queries:
{{SELECT partitionKey, clusteringColumn1, Max(value) FROM myTable WHERE
partitionKey=5 GROUP BY partitionKey, clusteringColumn1;}}
and {{SELECT partitionKey, clusteringColumn1, Max(value) FROM myTable WHERE
partitionKey=5 GROUP BY clusteringColumn1;}} will be both supported due to the
fact that the {{partitionKey}} column is restricted by an {{=}} operator.
> Add support for Group By to Select statement
>
>
> Key: CASSANDRA-10707
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10707
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>
> Now that Cassandra support aggregate functions, it makes sense to support
> {{GROUP BY}} on the {{SELECT}} statements.
> It should be possible to group either at the partition level or at the
> clustering column level.
> {code}
> SELECT partitionKey, max(value) FROM myTable GROUP BY partitionKey;
> SELECT partitionKey, clustering0, clustering1, max(value) FROM myTable GROUP
> BY partitionKey, clustering0, clustering1;
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
cassandra git commit: fix some javadoc errors
Repository: cassandra
Updated Branches:
refs/heads/trunk 5f83f6c29 -> 6b7db8a53
fix some javadoc errors
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/6b7db8a5
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/6b7db8a5
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/6b7db8a5
Branch: refs/heads/trunk
Commit: 6b7db8a534797d0ca7ebae506b265efd03e679ee
Parents: 5f83f6c
Author: Dave Brosius
Authored: Fri Jan 1 13:56:30 2016 -0500
Committer: Dave Brosius
Committed: Fri Jan 1 13:56:30 2016 -0500
--
src/java/org/apache/cassandra/auth/CassandraRoleManager.java | 2 +-
src/java/org/apache/cassandra/auth/IRoleManager.java | 2 +-
src/java/org/apache/cassandra/auth/RoleOptions.java | 2 +-
src/java/org/apache/cassandra/auth/Roles.java| 2 +-
src/java/org/apache/cassandra/config/CFMetaData.java | 2 +-
src/java/org/apache/cassandra/config/ViewDefinition.java | 4 +++-
src/java/org/apache/cassandra/cql3/QueryOptions.java | 2 +-
src/java/org/apache/cassandra/cql3/SingleColumnRelation.java | 2 +-
src/java/org/apache/cassandra/db/CompactTables.java | 2 ++
src/java/org/apache/cassandra/db/LegacyLayout.java | 2 +-
src/java/org/apache/cassandra/db/RangeTombstoneList.java | 2 +-
src/java/org/apache/cassandra/db/commitlog/CommitLog.java| 2 +-
src/java/org/apache/cassandra/db/lifecycle/LogReplicaSet.java| 3 ++-
.../cassandra/db/rows/UnfilteredRowIteratorSerializer.java | 2 ++
src/java/org/apache/cassandra/db/rows/UnfilteredSerializer.java | 2 ++
src/java/org/apache/cassandra/db/view/View.java | 3 ++-
src/java/org/apache/cassandra/db/view/ViewUtils.java | 2 +-
src/java/org/apache/cassandra/dht/ExcludingBounds.java | 2 +-
src/java/org/apache/cassandra/dht/IncludingExcludingBounds.java | 2 +-
src/java/org/apache/cassandra/index/Index.java | 4 ++--
.../apache/cassandra/index/internal/CassandraIndexFunctions.java | 2 +-
.../index/internal/composites/ClusteringColumnIndex.java | 2 ++
.../apache/cassandra/index/transactions/CleanupTransaction.java | 2 +-
.../apache/cassandra/index/transactions/IndexTransaction.java| 2 +-
.../apache/cassandra/index/transactions/UpdateTransaction.java | 2 +-
.../org/apache/cassandra/io/sstable/format/SSTableReader.java| 2 +-
.../apache/cassandra/io/sstable/metadata/MetadataSerializer.java | 2 +-
src/java/org/apache/cassandra/service/StorageServiceMBean.java | 4 ++--
src/java/org/apache/cassandra/utils/FastByteOperations.java | 2 +-
src/java/org/apache/cassandra/utils/SearchIterator.java | 2 +-
src/java/org/apache/cassandra/utils/UUIDGen.java | 2 +-
31 files changed, 41 insertions(+), 29 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/6b7db8a5/src/java/org/apache/cassandra/auth/CassandraRoleManager.java
--
diff --git a/src/java/org/apache/cassandra/auth/CassandraRoleManager.java
b/src/java/org/apache/cassandra/auth/CassandraRoleManager.java
index b34b648..826e89d 100644
--- a/src/java/org/apache/cassandra/auth/CassandraRoleManager.java
+++ b/src/java/org/apache/cassandra/auth/CassandraRoleManager.java
@@ -64,7 +64,7 @@ import org.mindrot.jbcrypt.BCrypt;
* in CREATE/ALTER ROLE statements.
*
* Such a configuration could be implemented using a custom IRoleManager that
- * extends CassandraRoleManager and which includes Option.PASSWORD in the
Set
+ * extends CassandraRoleManager and which includes Option.PASSWORD in the
{@code Set}
* returned from supportedOptions/alterableOptions. Any additional processing
* of the password itself (such as storing it in an alternative location) would
* be added in overridden createRole and alterRole implementations.
http://git-wip-us.apache.org/repos/asf/cassandra/blob/6b7db8a5/src/java/org/apache/cassandra/auth/IRoleManager.java
--
diff --git a/src/java/org/apache/cassandra/auth/IRoleManager.java
b/src/java/org/apache/cassandra/auth/IRoleManager.java
index 5afc7f3..b27681d 100644
--- a/src/java/org/apache/cassandra/auth/IRoleManager.java
+++ b/src/java/org/apache/cassandra/auth/IRoleManager.java
@@ -170,7 +170,7 @@ public interface IRoleManager
/**
* Where an implementation supports OPTIONS in CREATE and ALTER operations
- * this method should return the Map representing the
custom
+ * this method should return the {@code Map} representing
the custom
* options associated with the role, as supplied to CREATE or ALTER.
* It should never return null; if the
