[jira] [Updated] (CASSANDRA-15402) Make incremental backup configurable per keyspace and table
[ https://issues.apache.org/jira/browse/CASSANDRA-15402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Lerer updated CASSANDRA-15402: --- Reviewers: Benjamin Lerer, Marcus Eriksson, Michael Semb Wever, Stefan Miklosovic (was: Marcus Eriksson, Michael Semb Wever, Stefan Miklosovic) Status: Review In Progress (was: Needs Committer) > Make incremental backup configurable per keyspace and table > --- > > Key: CASSANDRA-15402 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15402 > Project: Cassandra > Issue Type: Improvement > Components: Local/Other, Tool/nodetool >Reporter: maxwellguo >Assignee: maxwellguo >Priority: Normal > Labels: pull-request-available > Fix For: 4.x > > Time Spent: 40m > Remaining Estimate: 0h > > We know that when we do backup for cassandra, we can do full bakcup with > snapshot, when we need to backup incremental data , incremental_backup can do > some help . > For snapshot we can just make snapshot for some keyspace/table. but > incremental backup will do all data backup(make hard link for all sstable > that flush from memtable or streaming ). we also know that commitlog's replay > can do some keyspace /table 's filter. > So I think for incremental backup we also need some filter for it.After all > not all keyspace/table is so important to do backup. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17811) CQL aggregation functions on collections, tuples and UDTs
[
https://issues.apache.org/jira/browse/CASSANDRA-17811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17635792#comment-17635792
]
Andres de la Peña commented on CASSANDRA-17811:
---
[~blerer] has approved the PR for the function factories on GitHub. Here is a
last CI round:
||Patch||CI||
|[trunk|https://github.com/apache/cassandra/pull/1844]|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/2504/workflows/6bee6bbc-8b44-4b43-8ee8-ad6c800ceb3d]
[j11|https://app.circleci.com/pipelines/github/adelapena/cassandra/2504/workflows/77c15def-f005-4206-8be8-b21d52436fb1]|
CI results are clean. I'll commit this and open a separate ticket for the
within-collection aggregation functions.
> CQL aggregation functions on collections, tuples and UDTs
> -
>
> Key: CASSANDRA-17811
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17811
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Semantics
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
>
> It has been found during CASSANDRA-8877 that CQLS's aggregation functions
> {{{}max{}}}, {{min}} and {{count}} can be applied to collections, but the
> result is returned as a blob. For example:
> {code:java}
> CREATE TABLE t (k int PRIMARY KEY, l list);
> INSERT INTO t(k, l) VALUES (0, [1, 2, 3]);
> INSERT INTO t(k, l) VALUES (1, [10, 20, 30]);
> SELECT max(l) FROM t;
> system.max(l)
>
> 0x00030004000a000400140004001e
> {code}
> This happens on 3.0, 3.11, 4.0, 4.1 and trunk.
> I'm not sure on whether the function shouldn't be supported for collections,
> or it should be supported but the result is wrong.
> In the example above, the returned blob is the serialized value of {{{}[10,
> 20, 30]{}}}, which is the right one according to the list comparator. I think
> this happens because the matched version of the function is the one for
> {{{}(blob) -> blob{}}}. We would need a {{(list) -> list}} function
> instead, but this function doesn't exist.
> It would be quite easy to add versions of the {{{}max{}}}, {{min}} and
> {{count}} functions for every type of collection ({{{}list{}}},
> {{{}list{}}}, {{{}map{}}}, {{{}map{}}}, etc.). The
> downside of this approach is that it would increase the number of aggregation
> functions kept in memory from 82 to 2722, if my maths are right. This is
> quite an increase, mainly due to the many possible combinations of the
> {{map}} type.
> [Here|https://github.com/adelapena/cassandra/commit/e3ba3c2dc36ce58d06942078c708ffb93eb3cd84]
> is a quick, incomplete prototype of the approach.
> Also, I'm not sure that applying those aggregation functions to collections
> is very useful in practice. Thus, an alternative approach would be just
> forbidding them, considering them not supported. I don't think it would be a
> problem for backward compatibility since no one has complained about the
> current behaviour, and we might well consider that the original intent was
> not to allow aggregation on collections. At least, there aren't any tests for
> it, and I can't find any documentation about it either.
> Another idea that comes to mind is that we could change the meaning of those
> functions to aggregate the values within the collection, instead of
> aggregating the rows. In that case, the behaviour would be:
> {code:java}
> CREATE TABLE t (k int PRIMARY KEY, l list);
> INSERT INTO t(k, l) VALUES (0, [1, 2, 3]);
> INSERT INTO t(k, l) VALUES (1, [10, 20, 30]);
> SELECT max(l) FROM t;
> k | system.max(l)
> ---+---
> 1 | 30
> 0 | 3
> {code}
> Of course we could have separate function names for that type of collection
> aggregations, like {{{}collectionMax{}}}, {{{}maxItem{}}}, or something like
> that.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17811) CQL aggregation functions on collections, tuples and UDTs
[
https://issues.apache.org/jira/browse/CASSANDRA-17811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andres de la Peña updated CASSANDRA-17811:
--
Status: Ready to Commit (was: Review In Progress)
> CQL aggregation functions on collections, tuples and UDTs
> -
>
> Key: CASSANDRA-17811
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17811
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Semantics
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
>
> It has been found during CASSANDRA-8877 that CQLS's aggregation functions
> {{{}max{}}}, {{min}} and {{count}} can be applied to collections, but the
> result is returned as a blob. For example:
> {code:java}
> CREATE TABLE t (k int PRIMARY KEY, l list);
> INSERT INTO t(k, l) VALUES (0, [1, 2, 3]);
> INSERT INTO t(k, l) VALUES (1, [10, 20, 30]);
> SELECT max(l) FROM t;
> system.max(l)
>
> 0x00030004000a000400140004001e
> {code}
> This happens on 3.0, 3.11, 4.0, 4.1 and trunk.
> I'm not sure on whether the function shouldn't be supported for collections,
> or it should be supported but the result is wrong.
> In the example above, the returned blob is the serialized value of {{{}[10,
> 20, 30]{}}}, which is the right one according to the list comparator. I think
> this happens because the matched version of the function is the one for
> {{{}(blob) -> blob{}}}. We would need a {{(list) -> list}} function
> instead, but this function doesn't exist.
> It would be quite easy to add versions of the {{{}max{}}}, {{min}} and
> {{count}} functions for every type of collection ({{{}list{}}},
> {{{}list{}}}, {{{}map{}}}, {{{}map{}}}, etc.). The
> downside of this approach is that it would increase the number of aggregation
> functions kept in memory from 82 to 2722, if my maths are right. This is
> quite an increase, mainly due to the many possible combinations of the
> {{map}} type.
> [Here|https://github.com/adelapena/cassandra/commit/e3ba3c2dc36ce58d06942078c708ffb93eb3cd84]
> is a quick, incomplete prototype of the approach.
> Also, I'm not sure that applying those aggregation functions to collections
> is very useful in practice. Thus, an alternative approach would be just
> forbidding them, considering them not supported. I don't think it would be a
> problem for backward compatibility since no one has complained about the
> current behaviour, and we might well consider that the original intent was
> not to allow aggregation on collections. At least, there aren't any tests for
> it, and I can't find any documentation about it either.
> Another idea that comes to mind is that we could change the meaning of those
> functions to aggregate the values within the collection, instead of
> aggregating the rows. In that case, the behaviour would be:
> {code:java}
> CREATE TABLE t (k int PRIMARY KEY, l list);
> INSERT INTO t(k, l) VALUES (0, [1, 2, 3]);
> INSERT INTO t(k, l) VALUES (1, [10, 20, 30]);
> SELECT max(l) FROM t;
> k | system.max(l)
> ---+---
> 1 | 30
> 0 | 3
> {code}
> Of course we could have separate function names for that type of collection
> aggregations, like {{{}collectionMax{}}}, {{{}maxItem{}}}, or something like
> that.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17811) CQL aggregation functions on collections, tuples and UDTs
[
https://issues.apache.org/jira/browse/CASSANDRA-17811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17635801#comment-17635801
]
Andres de la Peña commented on CASSANDRA-17811:
---
Committed to trunk as
[6da9e33602fad4b8bf9466dc0e9a73665469a195|https://github.com/apache/cassandra/commit/6da9e33602fad4b8bf9466dc0e9a73665469a195].
Thanks for the review.
> CQL aggregation functions on collections, tuples and UDTs
> -
>
> Key: CASSANDRA-17811
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17811
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Semantics
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
>
> It has been found during CASSANDRA-8877 that CQLS's aggregation functions
> {{{}max{}}}, {{min}} and {{count}} can be applied to collections, but the
> result is returned as a blob. For example:
> {code:java}
> CREATE TABLE t (k int PRIMARY KEY, l list);
> INSERT INTO t(k, l) VALUES (0, [1, 2, 3]);
> INSERT INTO t(k, l) VALUES (1, [10, 20, 30]);
> SELECT max(l) FROM t;
> system.max(l)
>
> 0x00030004000a000400140004001e
> {code}
> This happens on 3.0, 3.11, 4.0, 4.1 and trunk.
> I'm not sure on whether the function shouldn't be supported for collections,
> or it should be supported but the result is wrong.
> In the example above, the returned blob is the serialized value of {{{}[10,
> 20, 30]{}}}, which is the right one according to the list comparator. I think
> this happens because the matched version of the function is the one for
> {{{}(blob) -> blob{}}}. We would need a {{(list) -> list}} function
> instead, but this function doesn't exist.
> It would be quite easy to add versions of the {{{}max{}}}, {{min}} and
> {{count}} functions for every type of collection ({{{}list{}}},
> {{{}list{}}}, {{{}map{}}}, {{{}map{}}}, etc.). The
> downside of this approach is that it would increase the number of aggregation
> functions kept in memory from 82 to 2722, if my maths are right. This is
> quite an increase, mainly due to the many possible combinations of the
> {{map}} type.
> [Here|https://github.com/adelapena/cassandra/commit/e3ba3c2dc36ce58d06942078c708ffb93eb3cd84]
> is a quick, incomplete prototype of the approach.
> Also, I'm not sure that applying those aggregation functions to collections
> is very useful in practice. Thus, an alternative approach would be just
> forbidding them, considering them not supported. I don't think it would be a
> problem for backward compatibility since no one has complained about the
> current behaviour, and we might well consider that the original intent was
> not to allow aggregation on collections. At least, there aren't any tests for
> it, and I can't find any documentation about it either.
> Another idea that comes to mind is that we could change the meaning of those
> functions to aggregate the values within the collection, instead of
> aggregating the rows. In that case, the behaviour would be:
> {code:java}
> CREATE TABLE t (k int PRIMARY KEY, l list);
> INSERT INTO t(k, l) VALUES (0, [1, 2, 3]);
> INSERT INTO t(k, l) VALUES (1, [10, 20, 30]);
> SELECT max(l) FROM t;
> k | system.max(l)
> ---+---
> 1 | 30
> 0 | 3
> {code}
> Of course we could have separate function names for that type of collection
> aggregations, like {{{}collectionMax{}}}, {{{}maxItem{}}}, or something like
> that.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17811) CQL aggregation functions on collections, tuples and UDTs
[
https://issues.apache.org/jira/browse/CASSANDRA-17811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andres de la Peña updated CASSANDRA-17811:
--
Fix Version/s: 4.2
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
> CQL aggregation functions on collections, tuples and UDTs
> -
>
> Key: CASSANDRA-17811
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17811
> Project: Cassandra
> Issue Type: New Feature
> Components: CQL/Semantics
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 4.2
>
>
> It has been found during CASSANDRA-8877 that CQLS's aggregation functions
> {{{}max{}}}, {{min}} and {{count}} can be applied to collections, but the
> result is returned as a blob. For example:
> {code:java}
> CREATE TABLE t (k int PRIMARY KEY, l list);
> INSERT INTO t(k, l) VALUES (0, [1, 2, 3]);
> INSERT INTO t(k, l) VALUES (1, [10, 20, 30]);
> SELECT max(l) FROM t;
> system.max(l)
>
> 0x00030004000a000400140004001e
> {code}
> This happens on 3.0, 3.11, 4.0, 4.1 and trunk.
> I'm not sure on whether the function shouldn't be supported for collections,
> or it should be supported but the result is wrong.
> In the example above, the returned blob is the serialized value of {{{}[10,
> 20, 30]{}}}, which is the right one according to the list comparator. I think
> this happens because the matched version of the function is the one for
> {{{}(blob) -> blob{}}}. We would need a {{(list) -> list}} function
> instead, but this function doesn't exist.
> It would be quite easy to add versions of the {{{}max{}}}, {{min}} and
> {{count}} functions for every type of collection ({{{}list{}}},
> {{{}list{}}}, {{{}map{}}}, {{{}map{}}}, etc.). The
> downside of this approach is that it would increase the number of aggregation
> functions kept in memory from 82 to 2722, if my maths are right. This is
> quite an increase, mainly due to the many possible combinations of the
> {{map}} type.
> [Here|https://github.com/adelapena/cassandra/commit/e3ba3c2dc36ce58d06942078c708ffb93eb3cd84]
> is a quick, incomplete prototype of the approach.
> Also, I'm not sure that applying those aggregation functions to collections
> is very useful in practice. Thus, an alternative approach would be just
> forbidding them, considering them not supported. I don't think it would be a
> problem for backward compatibility since no one has complained about the
> current behaviour, and we might well consider that the original intent was
> not to allow aggregation on collections. At least, there aren't any tests for
> it, and I can't find any documentation about it either.
> Another idea that comes to mind is that we could change the meaning of those
> functions to aggregate the values within the collection, instead of
> aggregating the rows. In that case, the behaviour would be:
> {code:java}
> CREATE TABLE t (k int PRIMARY KEY, l list);
> INSERT INTO t(k, l) VALUES (0, [1, 2, 3]);
> INSERT INTO t(k, l) VALUES (1, [10, 20, 30]);
> SELECT max(l) FROM t;
> k | system.max(l)
> ---+---
> 1 | 30
> 0 | 3
> {code}
> Of course we could have separate function names for that type of collection
> aggregations, like {{{}collectionMax{}}}, {{{}maxItem{}}}, or something like
> that.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18059) Website downloads section should explain the noboolean repo
[ https://issues.apache.org/jira/browse/CASSANDRA-18059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Berenguer Blasi updated CASSANDRA-18059: Reviewers: Berenguer Blasi, Erick Ramirez, Berenguer Blasi (was: Erick Ramirez) Berenguer Blasi, Erick Ramirez, Berenguer Blasi (was: Berenguer Blasi, Erick Ramirez) Status: Review In Progress (was: Patch Available) > Website downloads section should explain the noboolean repo > --- > > Key: CASSANDRA-18059 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18059 > Project: Cassandra > Issue Type: Bug > Components: Documentation/Website >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > > After CASSANDRA-17765, there are two different repositories for Redhat-based > distros, depending on the distro's ability to understand simple boolean > logic. Currently we have no mention of the noboolean repo, causing users to > attempt to install the wrong package. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17811) CQL aggregation functions on collections, tuples and UDTs
[
https://issues.apache.org/jira/browse/CASSANDRA-17811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andres de la Peña updated CASSANDRA-17811:
--
Workflow: Copy of Cassandra Default Workflow (was: Copy of Cassandra Bug
Workflow)
Issue Type: New Feature (was: Bug)
> CQL aggregation functions on collections, tuples and UDTs
> -
>
> Key: CASSANDRA-17811
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17811
> Project: Cassandra
> Issue Type: New Feature
> Components: CQL/Semantics
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
>
> It has been found during CASSANDRA-8877 that CQLS's aggregation functions
> {{{}max{}}}, {{min}} and {{count}} can be applied to collections, but the
> result is returned as a blob. For example:
> {code:java}
> CREATE TABLE t (k int PRIMARY KEY, l list);
> INSERT INTO t(k, l) VALUES (0, [1, 2, 3]);
> INSERT INTO t(k, l) VALUES (1, [10, 20, 30]);
> SELECT max(l) FROM t;
> system.max(l)
>
> 0x00030004000a000400140004001e
> {code}
> This happens on 3.0, 3.11, 4.0, 4.1 and trunk.
> I'm not sure on whether the function shouldn't be supported for collections,
> or it should be supported but the result is wrong.
> In the example above, the returned blob is the serialized value of {{{}[10,
> 20, 30]{}}}, which is the right one according to the list comparator. I think
> this happens because the matched version of the function is the one for
> {{{}(blob) -> blob{}}}. We would need a {{(list) -> list}} function
> instead, but this function doesn't exist.
> It would be quite easy to add versions of the {{{}max{}}}, {{min}} and
> {{count}} functions for every type of collection ({{{}list{}}},
> {{{}list{}}}, {{{}map{}}}, {{{}map{}}}, etc.). The
> downside of this approach is that it would increase the number of aggregation
> functions kept in memory from 82 to 2722, if my maths are right. This is
> quite an increase, mainly due to the many possible combinations of the
> {{map}} type.
> [Here|https://github.com/adelapena/cassandra/commit/e3ba3c2dc36ce58d06942078c708ffb93eb3cd84]
> is a quick, incomplete prototype of the approach.
> Also, I'm not sure that applying those aggregation functions to collections
> is very useful in practice. Thus, an alternative approach would be just
> forbidding them, considering them not supported. I don't think it would be a
> problem for backward compatibility since no one has complained about the
> current behaviour, and we might well consider that the original intent was
> not to allow aggregation on collections. At least, there aren't any tests for
> it, and I can't find any documentation about it either.
> Another idea that comes to mind is that we could change the meaning of those
> functions to aggregate the values within the collection, instead of
> aggregating the rows. In that case, the behaviour would be:
> {code:java}
> CREATE TABLE t (k int PRIMARY KEY, l list);
> INSERT INTO t(k, l) VALUES (0, [1, 2, 3]);
> INSERT INTO t(k, l) VALUES (1, [10, 20, 30]);
> SELECT max(l) FROM t;
> k | system.max(l)
> ---+---
> 1 | 30
> 0 | 3
> {code}
> Of course we could have separate function names for that type of collection
> aggregations, like {{{}collectionMax{}}}, {{{}maxItem{}}}, or something like
> that.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18059) Website downloads section should explain the noboolean repo
[ https://issues.apache.org/jira/browse/CASSANDRA-18059?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17635802#comment-17635802 ] Berenguer Blasi commented on CASSANDRA-18059: - LGTM +1 > Website downloads section should explain the noboolean repo > --- > > Key: CASSANDRA-18059 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18059 > Project: Cassandra > Issue Type: Bug > Components: Documentation/Website >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > > After CASSANDRA-17765, there are two different repositories for Redhat-based > distros, depending on the distro's ability to understand simple boolean > logic. Currently we have no mention of the noboolean repo, causing users to > attempt to install the wrong package. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18059) Website downloads section should explain the noboolean repo
[ https://issues.apache.org/jira/browse/CASSANDRA-18059?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17635802#comment-17635802 ] Berenguer Blasi edited comment on CASSANDRA-18059 at 11/18/22 10:40 AM: LGTM +1 Edit: Ops apologies I missed Erik was reviewing this one. was (Author: bereng): LGTM +1 > Website downloads section should explain the noboolean repo > --- > > Key: CASSANDRA-18059 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18059 > Project: Cassandra > Issue Type: Bug > Components: Documentation/Website >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > > After CASSANDRA-17765, there are two different repositories for Redhat-based > distros, depending on the distro's ability to understand simple boolean > logic. Currently we have no mention of the noboolean repo, causing users to > attempt to install the wrong package. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17811) CQL aggregation functions on collections, tuples and UDTs
[
https://issues.apache.org/jira/browse/CASSANDRA-17811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andres de la Peña updated CASSANDRA-17811:
--
Source Control Link:
https://github.com/apache/cassandra/commit/6da9e33602fad4b8bf9466dc0e9a73665469a195
(was: https://github.com/apache/cassandra/pull/1844)
> CQL aggregation functions on collections, tuples and UDTs
> -
>
> Key: CASSANDRA-17811
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17811
> Project: Cassandra
> Issue Type: New Feature
> Components: CQL/Semantics
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 4.2
>
>
> It has been found during CASSANDRA-8877 that CQLS's aggregation functions
> {{{}max{}}}, {{min}} and {{count}} can be applied to collections, but the
> result is returned as a blob. For example:
> {code:java}
> CREATE TABLE t (k int PRIMARY KEY, l list);
> INSERT INTO t(k, l) VALUES (0, [1, 2, 3]);
> INSERT INTO t(k, l) VALUES (1, [10, 20, 30]);
> SELECT max(l) FROM t;
> system.max(l)
>
> 0x00030004000a000400140004001e
> {code}
> This happens on 3.0, 3.11, 4.0, 4.1 and trunk.
> I'm not sure on whether the function shouldn't be supported for collections,
> or it should be supported but the result is wrong.
> In the example above, the returned blob is the serialized value of {{{}[10,
> 20, 30]{}}}, which is the right one according to the list comparator. I think
> this happens because the matched version of the function is the one for
> {{{}(blob) -> blob{}}}. We would need a {{(list) -> list}} function
> instead, but this function doesn't exist.
> It would be quite easy to add versions of the {{{}max{}}}, {{min}} and
> {{count}} functions for every type of collection ({{{}list{}}},
> {{{}list{}}}, {{{}map{}}}, {{{}map{}}}, etc.). The
> downside of this approach is that it would increase the number of aggregation
> functions kept in memory from 82 to 2722, if my maths are right. This is
> quite an increase, mainly due to the many possible combinations of the
> {{map}} type.
> [Here|https://github.com/adelapena/cassandra/commit/e3ba3c2dc36ce58d06942078c708ffb93eb3cd84]
> is a quick, incomplete prototype of the approach.
> Also, I'm not sure that applying those aggregation functions to collections
> is very useful in practice. Thus, an alternative approach would be just
> forbidding them, considering them not supported. I don't think it would be a
> problem for backward compatibility since no one has complained about the
> current behaviour, and we might well consider that the original intent was
> not to allow aggregation on collections. At least, there aren't any tests for
> it, and I can't find any documentation about it either.
> Another idea that comes to mind is that we could change the meaning of those
> functions to aggregate the values within the collection, instead of
> aggregating the rows. In that case, the behaviour would be:
> {code:java}
> CREATE TABLE t (k int PRIMARY KEY, l list);
> INSERT INTO t(k, l) VALUES (0, [1, 2, 3]);
> INSERT INTO t(k, l) VALUES (1, [10, 20, 30]);
> SELECT max(l) FROM t;
> k | system.max(l)
> ---+---
> 1 | 30
> 0 | 3
> {code}
> Of course we could have separate function names for that type of collection
> aggregations, like {{{}collectionMax{}}}, {{{}maxItem{}}}, or something like
> that.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-18060) Within collection aggregation functions
Andres de la Peña created CASSANDRA-18060:
-
Summary: Within collection aggregation functions
Key: CASSANDRA-18060
URL: https://issues.apache.org/jira/browse/CASSANDRA-18060
Project: Cassandra
Issue Type: New Feature
Components: CQL/Semantics
Reporter: Andres de la Peña
Assignee: Andres de la Peña
The new mechanism for building native functions introduced by CASSANDRA-17811
can be used to provide within-collection aggregation functions. We can use that
mechanism to add new CQL functions to get:
* The number of items in a collection.
* The max/min items of a collection.
* The sum/avg of the items of a numeric collection.
* The keys or the values of a map.
For example:
{code}
CREATE TABLE k.t (k int PRIMARY KEY, l list, m map);
INSERT INTO t(k, l, m) VALUES (0, [1, 2, 3], {1:10, 2:20, 3:30});
> SELECT map_keys(m), map_values(m) FROM t;
system.map_keys(m) | system.map_values(m)
+--
{1, 2, 3} | [10, 20, 30]
> SELECT collection_count(m), collection_count(l) FROM t;
system.collection_count(m) | system.collection_count(l)
+
3 | 3
> SELECT collection_min(l), collection_max(l) FROM t;
system.collection_min(l) | system.collection_max(l)
--+--
1 |3
> SELECT collection_sum(l), collection_avg(l) FROM t;
system.collection_sum(l) | system.collection_avg(l)
--+--
6 |2
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17811) CQL aggregation functions on collections, tuples and UDTs
[
https://issues.apache.org/jira/browse/CASSANDRA-17811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17635813#comment-17635813
]
Andres de la Peña commented on CASSANDRA-17811:
---
Created CASSANDRA-18060 for the new within collection aggregation functions.
> CQL aggregation functions on collections, tuples and UDTs
> -
>
> Key: CASSANDRA-17811
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17811
> Project: Cassandra
> Issue Type: New Feature
> Components: CQL/Semantics
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 4.2
>
>
> It has been found during CASSANDRA-8877 that CQLS's aggregation functions
> {{{}max{}}}, {{min}} and {{count}} can be applied to collections, but the
> result is returned as a blob. For example:
> {code:java}
> CREATE TABLE t (k int PRIMARY KEY, l list);
> INSERT INTO t(k, l) VALUES (0, [1, 2, 3]);
> INSERT INTO t(k, l) VALUES (1, [10, 20, 30]);
> SELECT max(l) FROM t;
> system.max(l)
>
> 0x00030004000a000400140004001e
> {code}
> This happens on 3.0, 3.11, 4.0, 4.1 and trunk.
> I'm not sure on whether the function shouldn't be supported for collections,
> or it should be supported but the result is wrong.
> In the example above, the returned blob is the serialized value of {{{}[10,
> 20, 30]{}}}, which is the right one according to the list comparator. I think
> this happens because the matched version of the function is the one for
> {{{}(blob) -> blob{}}}. We would need a {{(list) -> list}} function
> instead, but this function doesn't exist.
> It would be quite easy to add versions of the {{{}max{}}}, {{min}} and
> {{count}} functions for every type of collection ({{{}list{}}},
> {{{}list{}}}, {{{}map{}}}, {{{}map{}}}, etc.). The
> downside of this approach is that it would increase the number of aggregation
> functions kept in memory from 82 to 2722, if my maths are right. This is
> quite an increase, mainly due to the many possible combinations of the
> {{map}} type.
> [Here|https://github.com/adelapena/cassandra/commit/e3ba3c2dc36ce58d06942078c708ffb93eb3cd84]
> is a quick, incomplete prototype of the approach.
> Also, I'm not sure that applying those aggregation functions to collections
> is very useful in practice. Thus, an alternative approach would be just
> forbidding them, considering them not supported. I don't think it would be a
> problem for backward compatibility since no one has complained about the
> current behaviour, and we might well consider that the original intent was
> not to allow aggregation on collections. At least, there aren't any tests for
> it, and I can't find any documentation about it either.
> Another idea that comes to mind is that we could change the meaning of those
> functions to aggregate the values within the collection, instead of
> aggregating the rows. In that case, the behaviour would be:
> {code:java}
> CREATE TABLE t (k int PRIMARY KEY, l list);
> INSERT INTO t(k, l) VALUES (0, [1, 2, 3]);
> INSERT INTO t(k, l) VALUES (1, [10, 20, 30]);
> SELECT max(l) FROM t;
> k | system.max(l)
> ---+---
> 1 | 30
> 0 | 3
> {code}
> Of course we could have separate function names for that type of collection
> aggregations, like {{{}collectionMax{}}}, {{{}maxItem{}}}, or something like
> that.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17832) Change bin/cqlsh.py shebang to use PATH with env prefix
[
https://issues.apache.org/jira/browse/CASSANDRA-17832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17635826#comment-17635826
]
Stefan Miklosovic commented on CASSANDRA-17832:
---
For the record, I spent a little bit more time on this and what I noticed is
that if you take a look into bin/cqlsh, it is invoking python3 directly, here
(1). What that does is that it will iterate over "python3" and "python"
binaries and whatever command it finds and its version is greater than 3.6, it
will start it.
If you do a simple test by changing shebang in bin/cqlsh.py to "#!/usr/bin/env
python5" and you try to start bin/cqlsh, it will start it, because it will try
to run that python3 it found in shell script.
On the other hand, if you execute bin/cqlsh.py directly, without shell wrapper,
it will error out on python5 not found.
So, in a nutshell, this is effectively used only in case a user tries to
execute bin/cqlsh.py directly, which I would say is not going to happen in
practice at all. If cqlsh is invoked via shell, people can even specify their
own versions of Python to run that cqlsh.py with so it completely bypasses the
shebang.
If we accept this, I am ok. But ideally we might probably get what /usr/bin/env
python3 is resolving in that shell cqlsh script and we use that binary to parse
the version of. Because now it just uses "python3" wherever it is, not honoring
env et all.
(1) https://github.com/apache/cassandra/blob/trunk/bin/cqlsh#L80
> Change bin/cqlsh.py shebang to use PATH with env prefix
> ---
>
> Key: CASSANDRA-17832
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17832
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Brad Schoening
>Assignee: Brad Schoening
>Priority: Low
> Fix For: 4.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> For cqlsh.py this:
> #!/usr/bin/env python
> is preferable to the current hard coded /usr/bin/python3 which doesn't take
> into account the python interpreter preferences in the users PATH.
> '{{{}env{}}}' is a system binary in {{/usr/bin}} that searches {{$PATH}} for
> strings containing the provided argument and returns the first instance it
> finds. In the above syntax, {{env}} will search for the first instance of
> {{python}} in {{$PATH}} and return it.
> This is aligned with the recommendations in
> [https://peps.python.org/pep-0394/]
> For example, on a MacOS Monterey 12.5.1 with both xcode python and brew
> installed python:
>
> {code:java}
> % /usr/bin/python3 --version
> Python 3.8.9. (xcode python version)
> % /usr/bin/env python --version
> Python 3.10.6. (brew python version)
> % python --version
> Python 3.10.6. (default)
> {code}
> Thus, /usr/bin/python3 doesn't run the expected default python version
> Even the official Python tutorial uses the /usr/bin/env form of shebang:
> [https://docs.python.org/3/tutorial/interpreter.html]
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17832) Change bin/cqlsh.py shebang to use PATH with env prefix
[
https://issues.apache.org/jira/browse/CASSANDRA-17832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17635826#comment-17635826
]
Stefan Miklosovic edited comment on CASSANDRA-17832 at 11/18/22 11:35 AM:
--
For the record, I spent a little bit more time on this and what I noticed is
that if you take a look into bin/cqlsh, it is invoking python3 directly, here
(1,2). What that does is that it will iterate over "python3" and "python"
binaries and whatever command it finds and its version is greater than 3.6, it
will start it.
If you do a simple test by changing shebang in bin/cqlsh.py to "#!/usr/bin/env
python5" and you try to start bin/cqlsh, it will start it, because it will try
to run that python3 it found in shell script.
On the other hand, if you execute bin/cqlsh.py directly, without shell wrapper,
it will error out on python5 not found.
So, in a nutshell, this is effectively used only in case a user tries to
execute bin/cqlsh.py directly, which I would say is not going to happen in
practice at all. If cqlsh is invoked via shell, people can even specify their
own versions of Python to run that cqlsh.py with so it completely bypasses the
shebang.
If we accept this, I am ok. But ideally we might probably get what /usr/bin/env
python3 is resolving in that shell cqlsh script and we use that binary to parse
the version of. Because now it just uses "python3" wherever it is, not honoring
env et all.
(1) https://github.com/apache/cassandra/blob/trunk/bin/cqlsh#L80
(2) https://github.com/apache/cassandra/blob/trunk/bin/cqlsh#L93
was (Author: smiklosovic):
For the record, I spent a little bit more time on this and what I noticed is
that if you take a look into bin/cqlsh, it is invoking python3 directly, here
(1). What that does is that it will iterate over "python3" and "python"
binaries and whatever command it finds and its version is greater than 3.6, it
will start it.
If you do a simple test by changing shebang in bin/cqlsh.py to "#!/usr/bin/env
python5" and you try to start bin/cqlsh, it will start it, because it will try
to run that python3 it found in shell script.
On the other hand, if you execute bin/cqlsh.py directly, without shell wrapper,
it will error out on python5 not found.
So, in a nutshell, this is effectively used only in case a user tries to
execute bin/cqlsh.py directly, which I would say is not going to happen in
practice at all. If cqlsh is invoked via shell, people can even specify their
own versions of Python to run that cqlsh.py with so it completely bypasses the
shebang.
If we accept this, I am ok. But ideally we might probably get what /usr/bin/env
python3 is resolving in that shell cqlsh script and we use that binary to parse
the version of. Because now it just uses "python3" wherever it is, not honoring
env et all.
(1) https://github.com/apache/cassandra/blob/trunk/bin/cqlsh#L80
> Change bin/cqlsh.py shebang to use PATH with env prefix
> ---
>
> Key: CASSANDRA-17832
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17832
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Brad Schoening
>Assignee: Brad Schoening
>Priority: Low
> Fix For: 4.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> For cqlsh.py this:
> #!/usr/bin/env python
> is preferable to the current hard coded /usr/bin/python3 which doesn't take
> into account the python interpreter preferences in the users PATH.
> '{{{}env{}}}' is a system binary in {{/usr/bin}} that searches {{$PATH}} for
> strings containing the provided argument and returns the first instance it
> finds. In the above syntax, {{env}} will search for the first instance of
> {{python}} in {{$PATH}} and return it.
> This is aligned with the recommendations in
> [https://peps.python.org/pep-0394/]
> For example, on a MacOS Monterey 12.5.1 with both xcode python and brew
> installed python:
>
> {code:java}
> % /usr/bin/python3 --version
> Python 3.8.9. (xcode python version)
> % /usr/bin/env python --version
> Python 3.10.6. (brew python version)
> % python --version
> Python 3.10.6. (default)
> {code}
> Thus, /usr/bin/python3 doesn't run the expected default python version
> Even the official Python tutorial uses the /usr/bin/env form of shebang:
> [https://docs.python.org/3/tutorial/interpreter.html]
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17832) Change bin/cqlsh.py shebang to use PATH with env prefix
[
https://issues.apache.org/jira/browse/CASSANDRA-17832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17635827#comment-17635827
]
Brandon Williams commented on CASSANDRA-17832:
--
What the shell script does is orthogonal to the correctness of using env, and
there is setup.py so I think it still makes sense to commit this.
> Change bin/cqlsh.py shebang to use PATH with env prefix
> ---
>
> Key: CASSANDRA-17832
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17832
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Brad Schoening
>Assignee: Brad Schoening
>Priority: Low
> Fix For: 4.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> For cqlsh.py this:
> #!/usr/bin/env python
> is preferable to the current hard coded /usr/bin/python3 which doesn't take
> into account the python interpreter preferences in the users PATH.
> '{{{}env{}}}' is a system binary in {{/usr/bin}} that searches {{$PATH}} for
> strings containing the provided argument and returns the first instance it
> finds. In the above syntax, {{env}} will search for the first instance of
> {{python}} in {{$PATH}} and return it.
> This is aligned with the recommendations in
> [https://peps.python.org/pep-0394/]
> For example, on a MacOS Monterey 12.5.1 with both xcode python and brew
> installed python:
>
> {code:java}
> % /usr/bin/python3 --version
> Python 3.8.9. (xcode python version)
> % /usr/bin/env python --version
> Python 3.10.6. (brew python version)
> % python --version
> Python 3.10.6. (default)
> {code}
> Thus, /usr/bin/python3 doesn't run the expected default python version
> Even the official Python tutorial uses the /usr/bin/env form of shebang:
> [https://docs.python.org/3/tutorial/interpreter.html]
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17832) Change bin/cqlsh.py shebang to use PATH with env prefix
[
https://issues.apache.org/jira/browse/CASSANDRA-17832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17635826#comment-17635826
]
Stefan Miklosovic edited comment on CASSANDRA-17832 at 11/18/22 11:49 AM:
--
For the record, I spent a little bit more time on this and what I noticed is
that if you take a look into bin/cqlsh, it is invoking python3 directly, here
(1,2). What that does is that it will iterate over "python3" and "python"
binaries and whatever command it finds and its version is greater than 3.6, it
will start it.
If you do a simple test by changing shebang in bin/cqlsh.py to "#!/usr/bin/env
python5" and you try to start bin/cqlsh, it will start it, because it will try
to run that python3 it found in shell script.
On the other hand, if you execute bin/cqlsh.py directly, without shell wrapper,
it will error out on python5 not found.
So, in a nutshell, this is effectively used only in case a user tries to
execute bin/cqlsh.py directly, which I would say is not going to happen in
practice at all. If cqlsh is invoked via shell, people can even specify their
own versions of Python to run that cqlsh.py with so it completely bypasses the
shebang.
If we accept this, I am ok. But ideally we might probably get what /usr/bin/env
python3 is resolving in that shell cqlsh script and we use that binary to parse
the version of. Because now it just uses "python3" wherever it is, not honoring
env et all.
Actually, the documentation of env command here (3) says (sectin 23.2.2):
_When a script’s interpreter is in a non-standard location in the PATH
environment variable, it is recommended to use env on the first line of the
script to find the executable and run it:_
So if I have my python3 in my PATH variable, it will try to use that one first,
presumably. But we are not doing the same thing in shell bin/cqlsh, do we? I
would like to know what python3 we are going to use, what interpreter is going
to be used in (1), when I have python3 in my PATH. Ideally it should use that
one, same as it will do by doing it by "env".
(1) https://github.com/apache/cassandra/blob/trunk/bin/cqlsh#L80
(2) https://github.com/apache/cassandra/blob/trunk/bin/cqlsh#L93
(3)
https://www.gnu.org/software/coreutils/manual/html_node/env-invocation.html#env-invocation
was (Author: smiklosovic):
For the record, I spent a little bit more time on this and what I noticed is
that if you take a look into bin/cqlsh, it is invoking python3 directly, here
(1,2). What that does is that it will iterate over "python3" and "python"
binaries and whatever command it finds and its version is greater than 3.6, it
will start it.
If you do a simple test by changing shebang in bin/cqlsh.py to "#!/usr/bin/env
python5" and you try to start bin/cqlsh, it will start it, because it will try
to run that python3 it found in shell script.
On the other hand, if you execute bin/cqlsh.py directly, without shell wrapper,
it will error out on python5 not found.
So, in a nutshell, this is effectively used only in case a user tries to
execute bin/cqlsh.py directly, which I would say is not going to happen in
practice at all. If cqlsh is invoked via shell, people can even specify their
own versions of Python to run that cqlsh.py with so it completely bypasses the
shebang.
If we accept this, I am ok. But ideally we might probably get what /usr/bin/env
python3 is resolving in that shell cqlsh script and we use that binary to parse
the version of. Because now it just uses "python3" wherever it is, not honoring
env et all.
(1) https://github.com/apache/cassandra/blob/trunk/bin/cqlsh#L80
(2) https://github.com/apache/cassandra/blob/trunk/bin/cqlsh#L93
> Change bin/cqlsh.py shebang to use PATH with env prefix
> ---
>
> Key: CASSANDRA-17832
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17832
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Brad Schoening
>Assignee: Brad Schoening
>Priority: Low
> Fix For: 4.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> For cqlsh.py this:
> #!/usr/bin/env python
> is preferable to the current hard coded /usr/bin/python3 which doesn't take
> into account the python interpreter preferences in the users PATH.
> '{{{}env{}}}' is a system binary in {{/usr/bin}} that searches {{$PATH}} for
> strings containing the provided argument and returns the first instance it
> finds. In the above syntax, {{env}} will search for the first instance of
> {{python}} in {{$PATH}} and return it.
> This is aligned with the recommendations in
> [https://peps.python.org/pep-0394/]
> For example, on a MacOS Monterey 12.5.1 with both xcode python and brew
> installed python:
>
>
[cassandra-website] branch asf-staging updated (ee0e6ddff -> eb53a9dbc)
This is an automated email from the ASF dual-hosted git repository. git-site-role pushed a change to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git discard ee0e6ddff generate docs for 37f7503b new eb53a9dbc generate docs for 37f7503b This update added new revisions after undoing existing revisions. That is to say, some revisions that were in the old version of the branch are not in the new version. This situation occurs when a user --force pushes a change and generates a repository containing something like this: * -- * -- B -- O -- O -- O (ee0e6ddff) \ N -- N -- N refs/heads/asf-staging (eb53a9dbc) You should already have received notification emails for all of the O revisions, and so the following emails describe only the N revisions from the common base, B. Any revisions marked "omit" are not gone; other references still refer to them. Any revisions marked "discard" are gone forever. The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: .../doc/4.2/cassandra/tools/nodetool/rebuild.html | 8 ++-- .../trunk/cassandra/tools/nodetool/rebuild.html| 8 ++-- content/search-index.js| 2 +- site-ui/build/ui-bundle.zip| Bin 4970139 -> 4970139 bytes 4 files changed, 13 insertions(+), 5 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17811) CQL functions on collections, tuples and UDTs
[
https://issues.apache.org/jira/browse/CASSANDRA-17811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andres de la Peña updated CASSANDRA-17811:
--
Summary: CQL functions on collections, tuples and UDTs (was: CQL
aggregation functions on collections, tuples and UDTs)
> CQL functions on collections, tuples and UDTs
> -
>
> Key: CASSANDRA-17811
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17811
> Project: Cassandra
> Issue Type: New Feature
> Components: CQL/Semantics
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 4.2
>
>
> It has been found during CASSANDRA-8877 that CQLS's aggregation functions
> {{{}max{}}}, {{min}} and {{count}} can be applied to collections, but the
> result is returned as a blob. For example:
> {code:java}
> CREATE TABLE t (k int PRIMARY KEY, l list);
> INSERT INTO t(k, l) VALUES (0, [1, 2, 3]);
> INSERT INTO t(k, l) VALUES (1, [10, 20, 30]);
> SELECT max(l) FROM t;
> system.max(l)
>
> 0x00030004000a000400140004001e
> {code}
> This happens on 3.0, 3.11, 4.0, 4.1 and trunk.
> I'm not sure on whether the function shouldn't be supported for collections,
> or it should be supported but the result is wrong.
> In the example above, the returned blob is the serialized value of {{{}[10,
> 20, 30]{}}}, which is the right one according to the list comparator. I think
> this happens because the matched version of the function is the one for
> {{{}(blob) -> blob{}}}. We would need a {{(list) -> list}} function
> instead, but this function doesn't exist.
> It would be quite easy to add versions of the {{{}max{}}}, {{min}} and
> {{count}} functions for every type of collection ({{{}list{}}},
> {{{}list{}}}, {{{}map{}}}, {{{}map{}}}, etc.). The
> downside of this approach is that it would increase the number of aggregation
> functions kept in memory from 82 to 2722, if my maths are right. This is
> quite an increase, mainly due to the many possible combinations of the
> {{map}} type.
> [Here|https://github.com/adelapena/cassandra/commit/e3ba3c2dc36ce58d06942078c708ffb93eb3cd84]
> is a quick, incomplete prototype of the approach.
> Also, I'm not sure that applying those aggregation functions to collections
> is very useful in practice. Thus, an alternative approach would be just
> forbidding them, considering them not supported. I don't think it would be a
> problem for backward compatibility since no one has complained about the
> current behaviour, and we might well consider that the original intent was
> not to allow aggregation on collections. At least, there aren't any tests for
> it, and I can't find any documentation about it either.
> Another idea that comes to mind is that we could change the meaning of those
> functions to aggregate the values within the collection, instead of
> aggregating the rows. In that case, the behaviour would be:
> {code:java}
> CREATE TABLE t (k int PRIMARY KEY, l list);
> INSERT INTO t(k, l) VALUES (0, [1, 2, 3]);
> INSERT INTO t(k, l) VALUES (1, [10, 20, 30]);
> SELECT max(l) FROM t;
> k | system.max(l)
> ---+---
> 1 | 30
> 0 | 3
> {code}
> Of course we could have separate function names for that type of collection
> aggregations, like {{{}collectionMax{}}}, {{{}maxItem{}}}, or something like
> that.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17832) Change bin/cqlsh.py shebang to use PATH with env prefix
[
https://issues.apache.org/jira/browse/CASSANDRA-17832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17635847#comment-17635847
]
Stefan Miklosovic commented on CASSANDRA-17832:
---
OK.
I did this test:
1) I moved /usr/bin/python3 to /usr/bin/python5
2) I created a symlink /home/smiklosovic/bin/python3 to /usr/bin/python5
3) I removed "python" from (2) in my last comment so there is only "pyton3" to
find.
4) command "whereis python3" gives this
{code:java}
python3: /usr/bin/python3.8 /usr/bin/python3.8-config /usr/lib/python3.8
/usr/lib/python3.9 /usr/lib/python3 /etc/python3.8 /etc/python3
/usr/local/lib/python3.8 /usr/include/python3.8 /usr/share/python3
/home/smiklosovic/bin/python3 /usr/share/man/man1/python3.1.gz {code}
The only python3 executable is in "/home/smiklosovic/bin/python3"
Execution of "./bin/cqlsh" still starts ok. This is the proof that looking for
python3 will still resolve what is in PATH similarly as what env is doing.
> Change bin/cqlsh.py shebang to use PATH with env prefix
> ---
>
> Key: CASSANDRA-17832
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17832
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Brad Schoening
>Assignee: Brad Schoening
>Priority: Low
> Fix For: 4.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> For cqlsh.py this:
> #!/usr/bin/env python
> is preferable to the current hard coded /usr/bin/python3 which doesn't take
> into account the python interpreter preferences in the users PATH.
> '{{{}env{}}}' is a system binary in {{/usr/bin}} that searches {{$PATH}} for
> strings containing the provided argument and returns the first instance it
> finds. In the above syntax, {{env}} will search for the first instance of
> {{python}} in {{$PATH}} and return it.
> This is aligned with the recommendations in
> [https://peps.python.org/pep-0394/]
> For example, on a MacOS Monterey 12.5.1 with both xcode python and brew
> installed python:
>
> {code:java}
> % /usr/bin/python3 --version
> Python 3.8.9. (xcode python version)
> % /usr/bin/env python --version
> Python 3.10.6. (brew python version)
> % python --version
> Python 3.10.6. (default)
> {code}
> Thus, /usr/bin/python3 doesn't run the expected default python version
> Even the official Python tutorial uses the /usr/bin/env form of shebang:
> [https://docs.python.org/3/tutorial/interpreter.html]
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17832) Change bin/cqlsh.py shebang to use PATH with env prefix
[
https://issues.apache.org/jira/browse/CASSANDRA-17832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17635847#comment-17635847
]
Stefan Miklosovic edited comment on CASSANDRA-17832 at 11/18/22 12:46 PM:
--
OK.
I did this test:
1) I moved /usr/bin/python3 to /usr/bin/python5
2) I created a symlink /home/smiklosovic/bin/python3 to /usr/bin/python5
3) I removed "python" from (2) in my last comment so there is only "pyton3" to
find.
4) command "whereis python3" gives this
5) my PATH contains $HOME/bin
{code:java}
python3: /usr/bin/python3.8 /usr/bin/python3.8-config /usr/lib/python3.8
/usr/lib/python3.9 /usr/lib/python3 /etc/python3.8 /etc/python3
/usr/local/lib/python3.8 /usr/include/python3.8 /usr/share/python3
/home/smiklosovic/bin/python3 /usr/share/man/man1/python3.1.gz {code}
The only python3 executable is in "/home/smiklosovic/bin/python3"
Execution of "./bin/cqlsh" still starts ok. This is the proof that looking for
python3 will still resolve what is in PATH similarly as what env is doing.
was (Author: smiklosovic):
OK.
I did this test:
1) I moved /usr/bin/python3 to /usr/bin/python5
2) I created a symlink /home/smiklosovic/bin/python3 to /usr/bin/python5
3) I removed "python" from (2) in my last comment so there is only "pyton3" to
find.
4) command "whereis python3" gives this
{code:java}
python3: /usr/bin/python3.8 /usr/bin/python3.8-config /usr/lib/python3.8
/usr/lib/python3.9 /usr/lib/python3 /etc/python3.8 /etc/python3
/usr/local/lib/python3.8 /usr/include/python3.8 /usr/share/python3
/home/smiklosovic/bin/python3 /usr/share/man/man1/python3.1.gz {code}
The only python3 executable is in "/home/smiklosovic/bin/python3"
Execution of "./bin/cqlsh" still starts ok. This is the proof that looking for
python3 will still resolve what is in PATH similarly as what env is doing.
> Change bin/cqlsh.py shebang to use PATH with env prefix
> ---
>
> Key: CASSANDRA-17832
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17832
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Brad Schoening
>Assignee: Brad Schoening
>Priority: Low
> Fix For: 4.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> For cqlsh.py this:
> #!/usr/bin/env python
> is preferable to the current hard coded /usr/bin/python3 which doesn't take
> into account the python interpreter preferences in the users PATH.
> '{{{}env{}}}' is a system binary in {{/usr/bin}} that searches {{$PATH}} for
> strings containing the provided argument and returns the first instance it
> finds. In the above syntax, {{env}} will search for the first instance of
> {{python}} in {{$PATH}} and return it.
> This is aligned with the recommendations in
> [https://peps.python.org/pep-0394/]
> For example, on a MacOS Monterey 12.5.1 with both xcode python and brew
> installed python:
>
> {code:java}
> % /usr/bin/python3 --version
> Python 3.8.9. (xcode python version)
> % /usr/bin/env python --version
> Python 3.10.6. (brew python version)
> % python --version
> Python 3.10.6. (default)
> {code}
> Thus, /usr/bin/python3 doesn't run the expected default python version
> Even the official Python tutorial uses the /usr/bin/env form of shebang:
> [https://docs.python.org/3/tutorial/interpreter.html]
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18060) Within collection aggregation functions
[
https://issues.apache.org/jira/browse/CASSANDRA-18060?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andres de la Peña updated CASSANDRA-18060:
--
Description:
The new mechanism for dynamically building native functions introduced by
CASSANDRA-17811 can be used to provide within-collection aggregation functions.
We can use that mechanism to add new CQL functions to get:
* The number of items in a collection.
* The max/min items of a collection.
* The sum/avg of the items of a numeric collection.
* The keys or the values of a map.
For example:
{code:java}
CREATE TABLE k.t (k int PRIMARY KEY, l list, m map);
INSERT INTO t(k, l, m) VALUES (0, [1, 2, 3], {1:10, 2:20, 3:30});
> SELECT map_keys(m), map_values(m) FROM t;
system.map_keys(m) | system.map_values(m)
+--
{1, 2, 3} | [10, 20, 30]
> SELECT collection_count(m), collection_count(l) FROM t;
system.collection_count(m) | system.collection_count(l)
+
3 | 3
> SELECT collection_min(l), collection_max(l) FROM t;
system.collection_min(l) | system.collection_max(l)
--+--
1 |3
> SELECT collection_sum(l), collection_avg(l) FROM t;
system.collection_sum(l) | system.collection_avg(l)
--+--
6 |2
{code}
was:
The new mechanism for building native functions introduced by CASSANDRA-17811
can be used to provide within-collection aggregation functions. We can use that
mechanism to add new CQL functions to get:
* The number of items in a collection.
* The max/min items of a collection.
* The sum/avg of the items of a numeric collection.
* The keys or the values of a map.
For example:
{code}
CREATE TABLE k.t (k int PRIMARY KEY, l list, m map);
INSERT INTO t(k, l, m) VALUES (0, [1, 2, 3], {1:10, 2:20, 3:30});
> SELECT map_keys(m), map_values(m) FROM t;
system.map_keys(m) | system.map_values(m)
+--
{1, 2, 3} | [10, 20, 30]
> SELECT collection_count(m), collection_count(l) FROM t;
system.collection_count(m) | system.collection_count(l)
+
3 | 3
> SELECT collection_min(l), collection_max(l) FROM t;
system.collection_min(l) | system.collection_max(l)
--+--
1 |3
> SELECT collection_sum(l), collection_avg(l) FROM t;
system.collection_sum(l) | system.collection_avg(l)
--+--
6 |2
{code}
> Within collection aggregation functions
> ---
>
> Key: CASSANDRA-18060
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18060
> Project: Cassandra
> Issue Type: New Feature
> Components: CQL/Semantics
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
>
> The new mechanism for dynamically building native functions introduced by
> CASSANDRA-17811 can be used to provide within-collection aggregation
> functions. We can use that mechanism to add new CQL functions to get:
> * The number of items in a collection.
> * The max/min items of a collection.
> * The sum/avg of the items of a numeric collection.
> * The keys or the values of a map.
> For example:
> {code:java}
> CREATE TABLE k.t (k int PRIMARY KEY, l list, m map);
> INSERT INTO t(k, l, m) VALUES (0, [1, 2, 3], {1:10, 2:20, 3:30});
> > SELECT map_keys(m), map_values(m) FROM t;
> system.map_keys(m) | system.map_values(m)
> +--
> {1, 2, 3} | [10, 20, 30]
> > SELECT collection_count(m), collection_count(l) FROM t;
> system.collection_count(m) | system.collection_count(l)
> +
> 3 | 3
> > SELECT collection_min(l), collection_max(l) FROM t;
> system.collection_min(l) | system.collection_max(l)
> --+--
> 1 |3
> > SELECT collection_sum(l), collection_avg(l) FROM t;
> system.collection_sum(l) | system.collection_avg(l)
> --+--
> 6 |2
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cas
[jira] [Updated] (CASSANDRA-17811) Fix CQL aggregation functions for collections, tuples and UDTs
[
https://issues.apache.org/jira/browse/CASSANDRA-17811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andres de la Peña updated CASSANDRA-17811:
--
Summary: Fix CQL aggregation functions for collections, tuples and UDTs
(was: CQL functions on collections, tuples and UDTs)
> Fix CQL aggregation functions for collections, tuples and UDTs
> --
>
> Key: CASSANDRA-17811
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17811
> Project: Cassandra
> Issue Type: New Feature
> Components: CQL/Semantics
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 4.2
>
>
> It has been found during CASSANDRA-8877 that CQLS's aggregation functions
> {{{}max{}}}, {{min}} and {{count}} can be applied to collections, but the
> result is returned as a blob. For example:
> {code:java}
> CREATE TABLE t (k int PRIMARY KEY, l list);
> INSERT INTO t(k, l) VALUES (0, [1, 2, 3]);
> INSERT INTO t(k, l) VALUES (1, [10, 20, 30]);
> SELECT max(l) FROM t;
> system.max(l)
>
> 0x00030004000a000400140004001e
> {code}
> This happens on 3.0, 3.11, 4.0, 4.1 and trunk.
> I'm not sure on whether the function shouldn't be supported for collections,
> or it should be supported but the result is wrong.
> In the example above, the returned blob is the serialized value of {{{}[10,
> 20, 30]{}}}, which is the right one according to the list comparator. I think
> this happens because the matched version of the function is the one for
> {{{}(blob) -> blob{}}}. We would need a {{(list) -> list}} function
> instead, but this function doesn't exist.
> It would be quite easy to add versions of the {{{}max{}}}, {{min}} and
> {{count}} functions for every type of collection ({{{}list{}}},
> {{{}list{}}}, {{{}map{}}}, {{{}map{}}}, etc.). The
> downside of this approach is that it would increase the number of aggregation
> functions kept in memory from 82 to 2722, if my maths are right. This is
> quite an increase, mainly due to the many possible combinations of the
> {{map}} type.
> [Here|https://github.com/adelapena/cassandra/commit/e3ba3c2dc36ce58d06942078c708ffb93eb3cd84]
> is a quick, incomplete prototype of the approach.
> Also, I'm not sure that applying those aggregation functions to collections
> is very useful in practice. Thus, an alternative approach would be just
> forbidding them, considering them not supported. I don't think it would be a
> problem for backward compatibility since no one has complained about the
> current behaviour, and we might well consider that the original intent was
> not to allow aggregation on collections. At least, there aren't any tests for
> it, and I can't find any documentation about it either.
> Another idea that comes to mind is that we could change the meaning of those
> functions to aggregate the values within the collection, instead of
> aggregating the rows. In that case, the behaviour would be:
> {code:java}
> CREATE TABLE t (k int PRIMARY KEY, l list);
> INSERT INTO t(k, l) VALUES (0, [1, 2, 3]);
> INSERT INTO t(k, l) VALUES (1, [10, 20, 30]);
> SELECT max(l) FROM t;
> k | system.max(l)
> ---+---
> 1 | 30
> 0 | 3
> {code}
> Of course we could have separate function names for that type of collection
> aggregations, like {{{}collectionMax{}}}, {{{}maxItem{}}}, or something like
> that.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch trunk updated: Add noboolean example
This is an automated email from the ASF dual-hosted git repository. brandonwilliams pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra-website.git The following commit(s) were added to refs/heads/trunk by this push: new 9b5fa3b6d Add noboolean example 9b5fa3b6d is described below commit 9b5fa3b6d7be4a9fbb0d429fd7177bc0cb26c757 Author: Brandon Williams AuthorDate: Thu Nov 17 16:23:29 2022 -0600 Add noboolean example Patch by brandonwilliams; reviewed by bereng for CASSANDRA-18059 --- site-content/source/modules/ROOT/pages/download.adoc | 13 + 1 file changed, 13 insertions(+) diff --git a/site-content/source/modules/ROOT/pages/download.adoc b/site-content/source/modules/ROOT/pages/download.adoc index d4edc42e6..2c8805545 100644 --- a/site-content/source/modules/ROOT/pages/download.adoc +++ b/site-content/source/modules/ROOT/pages/download.adoc @@ -168,6 +168,7 @@ and repeat `sudo apt-get update`. The actual key may be different, you get it fr * The latest `` is `40x`. * For older releases, the `` can be one of `311x`, `30x`, or `22x`. * (Not all versions of Apache Cassandra are available, since building RPMs is a recent addition to the project.) +* For CentOS 7 and similar (rpm < 4.14), append the `noboolean` repository * Add the Apache repository of Cassandra to `/etc/yum.repos.d/cassandra.repo`, for example for the latest 4.0 version: @@ -179,8 +180,20 @@ baseurl=https://redhat.cassandra.apache.org/40x/ gpgcheck=1 repo_gpgcheck=1 gpgkey=https://downloads.apache.org/cassandra/KEYS +-- + +Or for CentOS 7: +[source] +-- +[cassandra] +name=Apache Cassandra +baseurl=https://redhat.cassandra.apache.org/40x/noboolean/ +gpgcheck=1 +repo_gpgcheck=1 +gpgkey=https://downloads.apache.org/cassandra/KEYS -- + * Install Cassandra, accepting the gpg key import prompts: [source] - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated: Add reasons to guardrail messages and consider guardrails in the error message for needed ALLOW FILTERING
This is an automated email from the ASF dual-hosted git repository.
adelapena pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra.git
The following commit(s) were added to refs/heads/trunk by this push:
new 9f99e72aae Add reasons to guardrail messages and consider guardrails
in the error message for needed ALLOW FILTERING
9f99e72aae is described below
commit 9f99e72aae812b86d277883601450bc0e7bb9463
Author: Andrés de la Peña
AuthorDate: Fri Nov 4 12:39:21 2022 +
Add reasons to guardrail messages and consider guardrails in the error
message for needed ALLOW FILTERING
* Add optional reason for guarding an operation to every guardrail
* Add reason for disabling ALLOW FILTERING into cassandra.yaml
* Consider allow_filtering_enabled guardrail in the error message for
needed ALLOW FILTERING
patch by Andrés de la Peña; reviewed by Berenguer Blasi and Josh McKenzie
for CASSANDRA-17967
---
CHANGES.txt| 1 +
conf/cassandra.yaml| 1 +
.../cql3/restrictions/StatementRestrictions.java | 37 +
.../cassandra/cql3/statements/BatchStatement.java | 2 +-
.../cassandra/cql3/statements/DeleteStatement.java | 7 ++-
.../cql3/statements/ModificationStatement.java | 14 +++--
.../cassandra/cql3/statements/SelectStatement.java | 12 ++--
.../cassandra/cql3/statements/UpdateStatement.java | 19 +--
.../statements/schema/CreateViewStatement.java | 3 +-
.../apache/cassandra/db/guardrails/EnableFlag.java | 19 ++-
.../apache/cassandra/db/guardrails/Guardrail.java | 19 ++-
.../apache/cassandra/db/guardrails/Guardrails.java | 34 +++-
.../cassandra/db/guardrails/MaxThreshold.java | 6 +-
.../cassandra/db/guardrails/MinThreshold.java | 6 +-
.../db/guardrails/PercentageThreshold.java | 6 +-
.../apache/cassandra/db/guardrails/Predicates.java | 4 +-
.../apache/cassandra/db/guardrails/Threshold.java | 4 +-
.../org/apache/cassandra/db/guardrails/Values.java | 4 +-
src/java/org/apache/cassandra/db/view/View.java| 3 +-
.../distributed/fuzz/SSTableGenerator.java | 3 +-
.../db/guardrails/GuardrailAllowFilteringTest.java | 27 -
.../cassandra/db/guardrails/GuardrailTester.java | 23 ++--
.../guardrails/GuardrailsConfigProviderTest.java | 1 +
.../cassandra/db/guardrails/GuardrailsTest.java| 64 +-
24 files changed, 240 insertions(+), 79 deletions(-)
diff --git a/CHANGES.txt b/CHANGES.txt
index 1728a8db8d..b1b3788dc4 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
4.2
+ * Add reasons to guardrail messages and consider guardrails in the error
message for needed ALLOW FILTERING (CASSANDRA-17967)
* Add support for CQL functions on collections, tuples and UDTs
(CASSANDRA-17811)
* Add flag to exclude nodes from local DC when running nodetool rebuild
(CASSANDRA-17870)
* Adding endpoint verification option to client_encryption_options
(CASSANDRA-18034)
diff --git a/conf/cassandra.yaml b/conf/cassandra.yaml
index ff074bddd7..ab15c87ebc 100644
--- a/conf/cassandra.yaml
+++ b/conf/cassandra.yaml
@@ -1814,6 +1814,7 @@ drop_compact_storage_enabled: false
# items_per_collection_fail_threshold: -1
#
# Guardrail to allow/disallow querying with ALLOW FILTERING. Defaults to true.
+# ALLOW FILTERING can potentially visit all the data in the table and have
unpredictable performance.
# allow_filtering_enabled: true
#
# Guardrail to allow/disallow setting SimpleStrategy via keyspace creation or
alteration. Defaults to true.
diff --git
a/src/java/org/apache/cassandra/cql3/restrictions/StatementRestrictions.java
b/src/java/org/apache/cassandra/cql3/restrictions/StatementRestrictions.java
index 8f8be94e1f..371bc589c3 100644
--- a/src/java/org/apache/cassandra/cql3/restrictions/StatementRestrictions.java
+++ b/src/java/org/apache/cassandra/cql3/restrictions/StatementRestrictions.java
@@ -28,6 +28,7 @@ import org.apache.cassandra.cql3.statements.Bound;
import org.apache.cassandra.cql3.statements.StatementType;
import org.apache.cassandra.db.*;
import org.apache.cassandra.db.filter.RowFilter;
+import org.apache.cassandra.db.guardrails.Guardrails;
import org.apache.cassandra.db.marshal.AbstractType;
import org.apache.cassandra.dht.*;
import org.apache.cassandra.exceptions.InvalidRequestException;
@@ -50,10 +51,15 @@ import static
org.apache.cassandra.cql3.statements.RequestValidations.invalidReq
*/
public final class StatementRestrictions
{
-public static final String REQUIRES_ALLOW_FILTERING_MESSAGE =
-"Cannot execute this query as it might involve data filtering and
" +
-"thus may have unpredictable performance. If you want to execute "
+
-"this query despite the performance unpredictability, use ALLOW
FILTERING";
+private static final String ALLOW_FILTERING_MESSAGE =
+
[jira] [Commented] (CASSANDRA-17967) Guardrail: allow_filtering_custom_error_message
[ https://issues.apache.org/jira/browse/CASSANDRA-17967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17635858#comment-17635858 ] Andres de la Peña commented on CASSANDRA-17967: --- Committed to trunk as [9f99e72aae812b86d277883601450bc0e7bb9463|https://github.com/apache/cassandra/commit/9f99e72aae812b86d277883601450bc0e7bb9463]. Thanks for the reviews. > Guardrail: allow_filtering_custom_error_message > --- > > Key: CASSANDRA-17967 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17967 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Guardrails >Reporter: Sarma Pydipally >Assignee: Andres de la Peña >Priority: Normal > Fix For: 4.2 > > Time Spent: 1h 50m > Remaining Estimate: 0h > > in Apache Cassandra Release Version 4.1 : > with "allow_filtering_enabled: false" option under guardrails : > regular users cannot run queries with allow filtering clause in SELECT > commands. Users get following error message : > :1:InvalidRequest: Error from server: code=2200 [Invalid query] > message="Guardrail allow_filtering violated: Querying with ALLOW FILTERING is > not allowed" > I propose for a new parameter in conf file : something like : > allow_filtering_custom_error_message and allow cluster operators to configure > custom message > so if someone runs a SELECT command along with "ALLOW FILTERING" > it should print ERROR : InvalidRequest:code=2202:message="STOP using > allow_filtering clause" > so this will allow the operators to stop users from running allow filtering > as well as give them to configure a custom error message. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17967) Guardrail: allow_filtering_custom_error_message
[ https://issues.apache.org/jira/browse/CASSANDRA-17967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andres de la Peña updated CASSANDRA-17967: -- Source Control Link: https://github.com/apache/cassandra/commit/9f99e72aae812b86d277883601450bc0e7bb9463 Resolution: Fixed Status: Resolved (was: Ready to Commit) > Guardrail: allow_filtering_custom_error_message > --- > > Key: CASSANDRA-17967 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17967 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Guardrails >Reporter: Sarma Pydipally >Assignee: Andres de la Peña >Priority: Normal > Fix For: 4.2 > > Time Spent: 1h 50m > Remaining Estimate: 0h > > in Apache Cassandra Release Version 4.1 : > with "allow_filtering_enabled: false" option under guardrails : > regular users cannot run queries with allow filtering clause in SELECT > commands. Users get following error message : > :1:InvalidRequest: Error from server: code=2200 [Invalid query] > message="Guardrail allow_filtering violated: Querying with ALLOW FILTERING is > not allowed" > I propose for a new parameter in conf file : something like : > allow_filtering_custom_error_message and allow cluster operators to configure > custom message > so if someone runs a SELECT command along with "ALLOW FILTERING" > it should print ERROR : InvalidRequest:code=2202:message="STOP using > allow_filtering clause" > so this will allow the operators to stop users from running allow filtering > as well as give them to configure a custom error message. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17832) Change bin/cqlsh.py shebang to use PATH with env prefix
[
https://issues.apache.org/jira/browse/CASSANDRA-17832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17635860#comment-17635860
]
Brandon Williams commented on CASSANDRA-17832:
--
Are we ready to commit?
> Change bin/cqlsh.py shebang to use PATH with env prefix
> ---
>
> Key: CASSANDRA-17832
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17832
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Brad Schoening
>Assignee: Brad Schoening
>Priority: Low
> Fix For: 4.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> For cqlsh.py this:
> #!/usr/bin/env python
> is preferable to the current hard coded /usr/bin/python3 which doesn't take
> into account the python interpreter preferences in the users PATH.
> '{{{}env{}}}' is a system binary in {{/usr/bin}} that searches {{$PATH}} for
> strings containing the provided argument and returns the first instance it
> finds. In the above syntax, {{env}} will search for the first instance of
> {{python}} in {{$PATH}} and return it.
> This is aligned with the recommendations in
> [https://peps.python.org/pep-0394/]
> For example, on a MacOS Monterey 12.5.1 with both xcode python and brew
> installed python:
>
> {code:java}
> % /usr/bin/python3 --version
> Python 3.8.9. (xcode python version)
> % /usr/bin/env python --version
> Python 3.10.6. (brew python version)
> % python --version
> Python 3.10.6. (default)
> {code}
> Thus, /usr/bin/python3 doesn't run the expected default python version
> Even the official Python tutorial uses the /usr/bin/env form of shebang:
> [https://docs.python.org/3/tutorial/interpreter.html]
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18060) Add aggregation scalar functions on collections, tuples and UDTs
[
https://issues.apache.org/jira/browse/CASSANDRA-18060?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andres de la Peña updated CASSANDRA-18060:
--
Summary: Add aggregation scalar functions on collections, tuples and UDTs
(was: Within collection aggregation functions)
> Add aggregation scalar functions on collections, tuples and UDTs
>
>
> Key: CASSANDRA-18060
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18060
> Project: Cassandra
> Issue Type: New Feature
> Components: CQL/Semantics
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
>
> The new mechanism for dynamically building native functions introduced by
> CASSANDRA-17811 can be used to provide within-collection aggregation
> functions. We can use that mechanism to add new CQL functions to get:
> * The number of items in a collection.
> * The max/min items of a collection.
> * The sum/avg of the items of a numeric collection.
> * The keys or the values of a map.
> For example:
> {code:java}
> CREATE TABLE k.t (k int PRIMARY KEY, l list, m map);
> INSERT INTO t(k, l, m) VALUES (0, [1, 2, 3], {1:10, 2:20, 3:30});
> > SELECT map_keys(m), map_values(m) FROM t;
> system.map_keys(m) | system.map_values(m)
> +--
> {1, 2, 3} | [10, 20, 30]
> > SELECT collection_count(m), collection_count(l) FROM t;
> system.collection_count(m) | system.collection_count(l)
> +
> 3 | 3
> > SELECT collection_min(l), collection_max(l) FROM t;
> system.collection_min(l) | system.collection_max(l)
> --+--
> 1 |3
> > SELECT collection_sum(l), collection_avg(l) FROM t;
> system.collection_sum(l) | system.collection_avg(l)
> --+--
> 6 |2
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch asf-staging updated (eb53a9dbc -> 6af2846ac)
This is an automated email from the ASF dual-hosted git repository. git-site-role pushed a change to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git discard eb53a9dbc generate docs for 37f7503b add 9b5fa3b6d Add noboolean example new 6af2846ac generate docs for 9b5fa3b6 This update added new revisions after undoing existing revisions. That is to say, some revisions that were in the old version of the branch are not in the new version. This situation occurs when a user --force pushes a change and generates a repository containing something like this: * -- * -- B -- O -- O -- O (eb53a9dbc) \ N -- N -- N refs/heads/asf-staging (6af2846ac) You should already have received notification emails for all of the O revisions, and so the following emails describe only the N revisions from the common base, B. Any revisions marked "omit" are not gone; other references still refer to them. Any revisions marked "discard" are gone forever. The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: content/_/download.html| 16 content/search-index.js| 2 +- .../source/modules/ROOT/pages/download.adoc| 13 + site-ui/build/ui-bundle.zip| Bin 4970139 -> 4970139 bytes 4 files changed, 30 insertions(+), 1 deletion(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18059) Website downloads section should explain the noboolean repo
[ https://issues.apache.org/jira/browse/CASSANDRA-18059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-18059: - Attachment: Screenshot_20221118_072315.png > Website downloads section should explain the noboolean repo > --- > > Key: CASSANDRA-18059 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18059 > Project: Cassandra > Issue Type: Bug > Components: Documentation/Website >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Attachments: Screenshot_20221118_072315.png > > > After CASSANDRA-17765, there are two different repositories for Redhat-based > distros, depending on the distro's ability to understand simple boolean > logic. Currently we have no mention of the noboolean repo, causing users to > attempt to install the wrong package. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18060) Add aggregation scalar functions on collections, tuples and UDTs
[
https://issues.apache.org/jira/browse/CASSANDRA-18060?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andres de la Peña updated CASSANDRA-18060:
--
Description:
The new mechanism for dynamically building native functions introduced by
CASSANDRA-17811 can be used to provide within-collection aggregation functions.
We can use that mechanism to add new CQL functions to get:
* The number of items in a collection.
* The max/min items of a collection.
* The sum/avg of the items of a numeric collection.
* The keys or the values of a map.
For example:
{code:java}
CREATE TABLE k.t (k int PRIMARY KEY, l list, m map);
INSERT INTO t(k, l, m) VALUES (0, [1, 2, 3], {1:10, 2:20, 3:30});
> SELECT map_keys(m), map_values(m) FROM t;
system.map_keys(m) | system.map_values(m)
+--
{1, 2, 3} | [10, 20, 30]
> SELECT collection_count(m), collection_count(l) FROM t;
system.collection_count(m) | system.collection_count(l)
+
3 | 3
> SELECT collection_min(l), collection_max(l) FROM t;
system.collection_min(l) | system.collection_max(l)
--+--
1 |3
> SELECT collection_sum(l), collection_avg(l) FROM t;
system.collection_sum(l) | system.collection_avg(l)
--+--
6 |2
{code}
Note that this type of aggregation is different from the kind of aggregation
provided by {{min}}, {{max}}, {{sum}} and {{avg}}, which aggregate entire
collections across rows. Here we only aggregate the items of a collection row
per row.
was:
The new mechanism for dynamically building native functions introduced by
CASSANDRA-17811 can be used to provide within-collection aggregation functions.
We can use that mechanism to add new CQL functions to get:
* The number of items in a collection.
* The max/min items of a collection.
* The sum/avg of the items of a numeric collection.
* The keys or the values of a map.
For example:
{code:java}
CREATE TABLE k.t (k int PRIMARY KEY, l list, m map);
INSERT INTO t(k, l, m) VALUES (0, [1, 2, 3], {1:10, 2:20, 3:30});
> SELECT map_keys(m), map_values(m) FROM t;
system.map_keys(m) | system.map_values(m)
+--
{1, 2, 3} | [10, 20, 30]
> SELECT collection_count(m), collection_count(l) FROM t;
system.collection_count(m) | system.collection_count(l)
+
3 | 3
> SELECT collection_min(l), collection_max(l) FROM t;
system.collection_min(l) | system.collection_max(l)
--+--
1 |3
> SELECT collection_sum(l), collection_avg(l) FROM t;
system.collection_sum(l) | system.collection_avg(l)
--+--
6 |2
{code}
> Add aggregation scalar functions on collections, tuples and UDTs
>
>
> Key: CASSANDRA-18060
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18060
> Project: Cassandra
> Issue Type: New Feature
> Components: CQL/Semantics
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
>
> The new mechanism for dynamically building native functions introduced by
> CASSANDRA-17811 can be used to provide within-collection aggregation
> functions. We can use that mechanism to add new CQL functions to get:
> * The number of items in a collection.
> * The max/min items of a collection.
> * The sum/avg of the items of a numeric collection.
> * The keys or the values of a map.
> For example:
> {code:java}
> CREATE TABLE k.t (k int PRIMARY KEY, l list, m map);
> INSERT INTO t(k, l, m) VALUES (0, [1, 2, 3], {1:10, 2:20, 3:30});
> > SELECT map_keys(m), map_values(m) FROM t;
> system.map_keys(m) | system.map_values(m)
> +--
> {1, 2, 3} | [10, 20, 30]
> > SELECT collection_count(m), collection_count(l) FROM t;
> system.collection_count(m) | system.collection_count(l)
> +
> 3 | 3
> > SELECT collection_min(l), collection_max(l) FROM t;
> system.collection_min(l) | system.collection_max(l)
> --+--
> 1 |3
> > SELECT collection_sum(l), collection_avg(l) FROM t;
> system.collection_sum(l) | system.collecti
[cassandra] branch trunk updated (9f99e72aae -> 3860a90c5f)
This is an automated email from the ASF dual-hosted git repository. smiklosovic pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git from 9f99e72aae Add reasons to guardrail messages and consider guardrails in the error message for needed ALLOW FILTERING add 3860a90c5f Change shebangs of Python scripts to resolve Python 3 from env command No new revisions were added by this update. Summary of changes: CHANGES.txt | 1 + bin/cqlsh.py| 2 +- pylib/setup.py | 2 +- redhat/cassandra.spec | 4 ++-- redhat/noboolean/cassandra.spec | 4 ++-- 5 files changed, 7 insertions(+), 6 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17832) Change bin/cqlsh.py shebang to use PATH with env prefix
[
https://issues.apache.org/jira/browse/CASSANDRA-17832?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-17832:
--
Fix Version/s: 4.2
(was: 4.x)
Source Control Link:
https://github.com/apache/cassandra/commit/3860a90c5fa9497c1e7858750244e04b25a7d351
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
yes we are, committed here
https://github.com/apache/cassandra/commit/3860a90c5fa9497c1e7858750244e04b25a7d351
> Change bin/cqlsh.py shebang to use PATH with env prefix
> ---
>
> Key: CASSANDRA-17832
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17832
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Brad Schoening
>Assignee: Brad Schoening
>Priority: Low
> Fix For: 4.2
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> For cqlsh.py this:
> #!/usr/bin/env python
> is preferable to the current hard coded /usr/bin/python3 which doesn't take
> into account the python interpreter preferences in the users PATH.
> '{{{}env{}}}' is a system binary in {{/usr/bin}} that searches {{$PATH}} for
> strings containing the provided argument and returns the first instance it
> finds. In the above syntax, {{env}} will search for the first instance of
> {{python}} in {{$PATH}} and return it.
> This is aligned with the recommendations in
> [https://peps.python.org/pep-0394/]
> For example, on a MacOS Monterey 12.5.1 with both xcode python and brew
> installed python:
>
> {code:java}
> % /usr/bin/python3 --version
> Python 3.8.9. (xcode python version)
> % /usr/bin/env python --version
> Python 3.10.6. (brew python version)
> % python --version
> Python 3.10.6. (default)
> {code}
> Thus, /usr/bin/python3 doesn't run the expected default python version
> Even the official Python tutorial uses the /usr/bin/env form of shebang:
> [https://docs.python.org/3/tutorial/interpreter.html]
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15402) Make incremental backup configurable per keyspace and table
[ https://issues.apache.org/jira/browse/CASSANDRA-15402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17635884#comment-17635884 ] Benjamin Lerer commented on CASSANDRA-15402: The patch looks good to me. Thanks [~maxwellguo]. > Make incremental backup configurable per keyspace and table > --- > > Key: CASSANDRA-15402 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15402 > Project: Cassandra > Issue Type: Improvement > Components: Local/Other, Tool/nodetool >Reporter: maxwellguo >Assignee: maxwellguo >Priority: Normal > Labels: pull-request-available > Fix For: 4.x > > Time Spent: 40m > Remaining Estimate: 0h > > We know that when we do backup for cassandra, we can do full bakcup with > snapshot, when we need to backup incremental data , incremental_backup can do > some help . > For snapshot we can just make snapshot for some keyspace/table. but > incremental backup will do all data backup(make hard link for all sstable > that flush from memtable or streaming ). we also know that commitlog's replay > can do some keyspace /table 's filter. > So I think for incremental backup we also need some filter for it.After all > not all keyspace/table is so important to do backup. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15402) Make incremental backup configurable per keyspace and table
[ https://issues.apache.org/jira/browse/CASSANDRA-15402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Lerer updated CASSANDRA-15402: --- Status: Ready to Commit (was: Review In Progress) > Make incremental backup configurable per keyspace and table > --- > > Key: CASSANDRA-15402 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15402 > Project: Cassandra > Issue Type: Improvement > Components: Local/Other, Tool/nodetool >Reporter: maxwellguo >Assignee: maxwellguo >Priority: Normal > Labels: pull-request-available > Fix For: 4.x > > Time Spent: 40m > Remaining Estimate: 0h > > We know that when we do backup for cassandra, we can do full bakcup with > snapshot, when we need to backup incremental data , incremental_backup can do > some help . > For snapshot we can just make snapshot for some keyspace/table. but > incremental backup will do all data backup(make hard link for all sstable > that flush from memtable or streaming ). we also know that commitlog's replay > can do some keyspace /table 's filter. > So I think for incremental backup we also need some filter for it.After all > not all keyspace/table is so important to do backup. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15402) Make incremental backup configurable per keyspace and table
[ https://issues.apache.org/jira/browse/CASSANDRA-15402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17635891#comment-17635891 ] Stefan Miklosovic commented on CASSANDRA-15402: --- Thanks [~blerer], I will commit soon. > Make incremental backup configurable per keyspace and table > --- > > Key: CASSANDRA-15402 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15402 > Project: Cassandra > Issue Type: Improvement > Components: Local/Other, Tool/nodetool >Reporter: maxwellguo >Assignee: maxwellguo >Priority: Normal > Labels: pull-request-available > Fix For: 4.x > > Time Spent: 40m > Remaining Estimate: 0h > > We know that when we do backup for cassandra, we can do full bakcup with > snapshot, when we need to backup incremental data , incremental_backup can do > some help . > For snapshot we can just make snapshot for some keyspace/table. but > incremental backup will do all data backup(make hard link for all sstable > that flush from memtable or streaming ). we also know that commitlog's replay > can do some keyspace /table 's filter. > So I think for incremental backup we also need some filter for it.After all > not all keyspace/table is so important to do backup. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch asf-site updated (52dac3a4d -> 6af2846ac)
This is an automated email from the ASF dual-hosted git repository.
brandonwilliams pushed a change to branch asf-site
in repository https://gitbox.apache.org/repos/asf/cassandra-website.git
discard 52dac3a4d generate docs for a67d0561
add 37f7503be Fixes to Testing page
add 9b5fa3b6d Add noboolean example
add 6af2846ac generate docs for 9b5fa3b6
This update added new revisions after undoing existing revisions.
That is to say, some revisions that were in the old version of the
branch are not in the new version. This situation occurs
when a user --force pushes a change and generates a repository
containing something like this:
* -- * -- B -- O -- O -- O (52dac3a4d)
\
N -- N -- N refs/heads/asf-site (6af2846ac)
You should already have received notification emails for all of the O
revisions, and so the following emails describe only the N revisions
from the common base, B.
Any revisions marked "omit" are not gone; other references still
refer to them. Any revisions marked "discard" are gone forever.
No new revisions were added by this update.
Summary of changes:
content/_/development/index.html | 11 ++--
content/_/development/testing.html | 11 ++--
content/_/download.html| 16 +
.../doc/4.0.0/cassandra/tools/nodetool/import.html | 6 +-
.../doc/4.0.1/cassandra/tools/nodetool/import.html | 6 +-
.../doc/4.0.2/cassandra/tools/nodetool/import.html | 6 +-
.../doc/4.0.3/cassandra/tools/nodetool/import.html | 6 +-
.../doc/4.0.4/cassandra/tools/nodetool/import.html | 6 +-
.../doc/4.0.5/cassandra/tools/nodetool/import.html | 6 +-
.../doc/4.0/cassandra/tools/nodetool/import.html | 6 +-
.../cassandra/configuration/cass_yaml_file.html| 14 +++--
.../doc/4.1/cassandra/tools/nodetool/import.html | 6 +-
.../cassandra/configuration/cass_yaml_file.html| 15 +++--
.../4.2/cassandra/tools/nodetool/bootstrap.html| 6 +-
.../{setdefaultrf.html => forcecompact.html} | 19 +++---
.../doc/4.2/cassandra/tools/nodetool/import.html | 6 +-
.../doc/4.2/cassandra/tools/nodetool/nodetool.html | 8 ++-
.../doc/4.2/cassandra/tools/nodetool/rebuild.html | 8 ++-
.../4.2/cassandra/tools/nodetool/repair_admin.html | 70 +++--
.../cassandra/configuration/cass_yaml_file.html| 14 +++--
.../latest/cassandra/tools/nodetool/import.html| 6 +-
.../stable/cassandra/tools/nodetool/import.html| 6 +-
.../cassandra/configuration/cass_yaml_file.html| 15 +++--
.../trunk/cassandra/tools/nodetool/bootstrap.html | 6 +-
.../cassandra/tools/nodetool/forcecompact.html}| 19 +++---
.../doc/trunk/cassandra/tools/nodetool/import.html | 6 +-
.../trunk/cassandra/tools/nodetool/nodetool.html | 8 ++-
.../trunk/cassandra/tools/nodetool/rebuild.html| 8 ++-
.../cassandra/tools/nodetool/repair_admin.html | 70 +++--
content/search-index.js| 2 +-
.../modules/ROOT/pages/development/testing.adoc| 11 ++--
.../source/modules/ROOT/pages/download.adoc| 13
site-ui/build/ui-bundle.zip| Bin 4970139 -> 4970139
bytes
33 files changed, 244 insertions(+), 172 deletions(-)
copy content/doc/4.2/cassandra/tools/nodetool/{setdefaultrf.html =>
forcecompact.html} (98%)
copy content/doc/{4.2/cassandra/tools/nodetool/setdefaultrf.html =>
trunk/cassandra/tools/nodetool/forcecompact.html} (98%)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18059) Website downloads section should explain the noboolean repo
[ https://issues.apache.org/jira/browse/CASSANDRA-18059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-18059: - Status: Ready to Commit (was: Review In Progress) > Website downloads section should explain the noboolean repo > --- > > Key: CASSANDRA-18059 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18059 > Project: Cassandra > Issue Type: Bug > Components: Documentation/Website >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Attachments: Screenshot_20221118_072315.png > > > After CASSANDRA-17765, there are two different repositories for Redhat-based > distros, depending on the distro's ability to understand simple boolean > logic. Currently we have no mention of the noboolean repo, causing users to > attempt to install the wrong package. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18059) Website downloads section should explain the noboolean repo
[ https://issues.apache.org/jira/browse/CASSANDRA-18059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-18059: - Reviewers: Berenguer Blasi (was: Berenguer Blasi, Erick Ramirez) > Website downloads section should explain the noboolean repo > --- > > Key: CASSANDRA-18059 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18059 > Project: Cassandra > Issue Type: Bug > Components: Documentation/Website >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Attachments: Screenshot_20221118_072315.png > > > After CASSANDRA-17765, there are two different repositories for Redhat-based > distros, depending on the distro's ability to understand simple boolean > logic. Currently we have no mention of the noboolean repo, causing users to > attempt to install the wrong package. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18059) Website downloads section should explain the noboolean repo
[ https://issues.apache.org/jira/browse/CASSANDRA-18059?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17635920#comment-17635920 ] Brandon Williams commented on CASSANDRA-18059: -- I was just being sheepish about my first website commit and was hoping someone with more experience would do it for me, so I set him as the reviewer. :) I've got it sorted though and it's now live, thanks! > Website downloads section should explain the noboolean repo > --- > > Key: CASSANDRA-18059 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18059 > Project: Cassandra > Issue Type: Bug > Components: Documentation/Website >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Attachments: Screenshot_20221118_072315.png > > > After CASSANDRA-17765, there are two different repositories for Redhat-based > distros, depending on the distro's ability to understand simple boolean > logic. Currently we have no mention of the noboolean repo, causing users to > attempt to install the wrong package. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18059) Website downloads section should explain the noboolean repo
[ https://issues.apache.org/jira/browse/CASSANDRA-18059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-18059: - Fix Version/s: NA Since Version: NA Source Control Link: https://github.com/apache/cassandra-website/commit/9b5fa3b6d7be4a9fbb0d429fd7177bc0cb26c757 Resolution: Fixed Status: Resolved (was: Ready to Commit) > Website downloads section should explain the noboolean repo > --- > > Key: CASSANDRA-18059 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18059 > Project: Cassandra > Issue Type: Bug > Components: Documentation/Website >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Fix For: NA > > Attachments: Screenshot_20221118_072315.png > > > After CASSANDRA-17765, there are two different repositories for Redhat-based > distros, depending on the distro's ability to understand simple boolean > logic. Currently we have no mention of the noboolean repo, causing users to > attempt to install the wrong package. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-builds] branch trunk updated: Add JDK 17 to the testing images patch by Ekaterina Dimitrova; reviewed by Michael Semb Wever and Brandon Williams for CASSANDRA-17854
This is an automated email from the ASF dual-hosted git repository. edimitrova pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra-builds.git The following commit(s) were added to refs/heads/trunk by this push: new cbdad2c Add JDK 17 to the testing images patch by Ekaterina Dimitrova; reviewed by Michael Semb Wever and Brandon Williams for CASSANDRA-17854 cbdad2c is described below commit cbdad2c546d4f6dc8ab9321a4c05be75311498c3 Author: Ekaterina Dimitrova AuthorDate: Wed Aug 24 11:08:24 2022 -0400 Add JDK 17 to the testing images patch by Ekaterina Dimitrova; reviewed by Michael Semb Wever and Brandon Williams for CASSANDRA-17854 --- docker/testing/ubuntu2004_j11.docker | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/docker/testing/ubuntu2004_j11.docker b/docker/testing/ubuntu2004_j11.docker index 38bb63a..e572a68 100644 --- a/docker/testing/ubuntu2004_j11.docker +++ b/docker/testing/ubuntu2004_j11.docker @@ -79,7 +79,7 @@ RUN pip3 install --upgrade wheel # openjdk + ant RUN export DEBIAN_FRONTEND=noninteractive && \ apt-get update && \ -apt-get install -y --no-install-recommends openjdk-8-jdk openjdk-11-jdk ant ant-optional +apt-get install -y --no-install-recommends openjdk-8-jdk openjdk-11-jdk openjdk-17-jdk ant ant-optional # make Java 8 the default executable (we use to run all tests against Java 8) RUN update-java-alternatives --set java-1.8.0-openjdk-$(dpkg --print-architecture) @@ -108,6 +108,7 @@ WORKDIR /home/cassandra RUN echo 'export ANT_HOME=/usr/share/ant' >> /home/cassandra/.bashrc && \ echo 'export JAVA8_HOME=/usr/lib/jvm/java-8-openjdk-$(dpkg --print-architecture)' >> /home/cassandra/.bashrc && \ echo 'export JAVA11_HOME=/usr/lib/jvm/java-11-openjdk-$(dpkg --print-architecture)' >> /home/cassandra/.bashrc && \ +echo 'export JAVA17_HOME=/usr/lib/jvm/java-17-openjdk-$(dpkg --print-architecture)' >> /home/cassandra/.bashrc && \ echo 'export JAVA_HOME=$JAVA8_HOME' >> /home/cassandra/.bashrc ENV ANT_HOME=/usr/share/ant - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRASC-47) Introduce JMX foundation in Sidecar
[ https://issues.apache.org/jira/browse/CASSANDRASC-47?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yifan Cai updated CASSANDRASC-47: - Status: Ready to Commit (was: Review In Progress) > Introduce JMX foundation in Sidecar > --- > > Key: CASSANDRASC-47 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-47 > Project: Sidecar for Apache Cassandra > Issue Type: Improvement > Components: Rest API >Reporter: Francisco Guerrero >Assignee: Francisco Guerrero >Priority: Normal > Labels: pull-request-available > > Currently, Sidecar supports CQL access to the Cassandra instances it manages. > However, JMX support is not available at the moment. We need to introduce the > JMX foundation in Sidecar to support additional interactions with Cassandra > instances that are not available through the CQL protocol. > This ticket is intended for introducing the JMX foundation, that can later be > used for adding new functionality to Sidecar interactions with Cassandra > through JMX. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRASC-47) Introduce JMX foundation in Sidecar
[ https://issues.apache.org/jira/browse/CASSANDRASC-47?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yifan Cai updated CASSANDRASC-47: - Status: Review In Progress (was: Needs Committer) > Introduce JMX foundation in Sidecar > --- > > Key: CASSANDRASC-47 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-47 > Project: Sidecar for Apache Cassandra > Issue Type: Improvement > Components: Rest API >Reporter: Francisco Guerrero >Assignee: Francisco Guerrero >Priority: Normal > Labels: pull-request-available > > Currently, Sidecar supports CQL access to the Cassandra instances it manages. > However, JMX support is not available at the moment. We need to introduce the > JMX foundation in Sidecar to support additional interactions with Cassandra > instances that are not available through the CQL protocol. > This ticket is intended for introducing the JMX foundation, that can later be > used for adding new functionality to Sidecar interactions with Cassandra > through JMX. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch asf-staging updated (6af2846ac -> d749d6088)
This is an automated email from the ASF dual-hosted git repository. git-site-role pushed a change to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git omit 6af2846ac generate docs for 9b5fa3b6 new d749d6088 generate docs for 9b5fa3b6 This update added new revisions after undoing existing revisions. That is to say, some revisions that were in the old version of the branch are not in the new version. This situation occurs when a user --force pushes a change and generates a repository containing something like this: * -- * -- B -- O -- O -- O (6af2846ac) \ N -- N -- N refs/heads/asf-staging (d749d6088) You should already have received notification emails for all of the O revisions, and so the following emails describe only the N revisions from the common base, B. Any revisions marked "omit" are not gone; other references still refer to them. Any revisions marked "discard" are gone forever. The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: .../cassandra/configuration/cass_yaml_file.html| 3 ++- .../cassandra/configuration/cass_yaml_file.html| 3 ++- site-ui/build/ui-bundle.zip| Bin 4970139 -> 4970139 bytes 3 files changed, 4 insertions(+), 2 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-sidecar] branch trunk updated: CASSANDRASC-47: Introduce JMX foundation in Sidecar
This is an automated email from the ASF dual-hosted git repository. ycai pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra-sidecar.git The following commit(s) were added to refs/heads/trunk by this push: new 02cc654 CASSANDRASC-47: Introduce JMX foundation in Sidecar 02cc654 is described below commit 02cc6548f291528e9749a51d103463f9552f4b4e Author: Francisco Guerrero AuthorDate: Wed Nov 2 12:54:54 2022 -0700 CASSANDRASC-47: Introduce JMX foundation in Sidecar In this commit, we introduce the JMX foundation in Sidecar to enable the ability to communicate with the Cassandra process. This commit adds new configuration parameters to configure the a `org.apache.cassandra.sidecar.common.JmxClient`. This client is available as part of the Cassandra delegate. A new interface is introduced and exposed through the `org.apache.cassandra.sidecar.common.ICassandraAdapter`. The new interface `StorageOperations` is intended to interface with the Cassandra StorageService. This commit provides an example implementation of the `takeSnapshot` method, which is also found in the Cassandra code base. This should allow us to interact with the Cassandra process to create snapshots. A fix is required in the `CassandraSidecarDaemon` class, where the `healthCheck` runs the first time only after the configured health check frequency (millis) has passed. This causes issues in the unit tests as well as the actual execution of the service, as the `adapter` will be `null` until the first health check is performed. To fix this issue, we perform a health check right after the server successfully starts up. Additional integration tests are added for testing the JMX integration with Cassandra. In the test, we spin up a new Cassandra container using `testcontainers` and we perform validation against the StorageService in Cassandra. Co-authored-by: Doug Rohrer patch by Francisco Guerrero, Doug Rohrer; reviewed by Yifan Cai, Dinesh Joshi for CASSANDRASC-47 --- CHANGES.txt| 5 + build.gradle | 8 +- cassandra-integration-tests/build.gradle | 15 +- .../cassandra/sidecar/common/DelegateTest.java | 7 +- .../cassandra/sidecar/common/JmxClientTest.java| 58 + .../common/containers/CassandraContainer.java | 50 .../common/testing/CassandraIntegrationTest.java | 0 .../common/testing/CassandraTestContext.java | 23 +- .../common/testing/CassandraTestTemplate.java | 79 --- .../sidecar/common/testing/TestVersion.java| 0 .../common/testing/TestVersionSupplier.java| 4 +- cassandra40/build.gradle | 1 + .../sidecar/cassandra40/Cassandra40Factory.java| 30 ++- .../cassandra40/Cassandra40StorageOperations.java | 61 + .../sidecar/cassandra40/StorageJmxOperations.java | 18 ++ .../cassandra/sidecar/common/CQLSession.java | 20 +- .../sidecar/common/CassandraAdapterDelegate.java | 14 +- .../sidecar/common/ICassandraAdapter.java | 5 + .../sidecar/common/ICassandraFactory.java | 9 +- .../apache/cassandra/sidecar/common/JmxClient.java | 209 + .../sidecar/common/MockCassandraFactory.java | 2 +- ...assandraAdapter.java => StorageOperations.java} | 24 +- .../org/apache/cassandra/sidecar/mocks/V30.java| 3 +- .../org/apache/cassandra/sidecar/mocks/V40.java| 3 +- .../org/apache/cassandra/sidecar/mocks/V41.java| 3 +- .../cassandra/sidecar/common/JmxClientTest.java| 251 .../src/test/resources/testJmxPassword.properties | 1 + spotbugs-exclude.xml | 11 +- src/main/dist/conf/sidecar.yaml| 10 + .../cassandra/sidecar/CassandraSidecarDaemon.java | 44 +++- .../apache/cassandra/sidecar/Configuration.java| 23 +- .../org/apache/cassandra/sidecar/MainModule.java | 144 +--- .../sidecar/YAMLSidecarConfiguration.java | 261 + .../sidecar/cluster/InstancesConfigImpl.java | 6 + .../sidecar/cluster/instance/InstanceMetadata.java | 18 +- .../cluster/instance/InstanceMetadataImpl.java | 34 ++- .../cassandra/sidecar/utils/YAMLKeyConstants.java | 7 + .../cassandra/sidecar/ConfigurationTest.java | 118 -- .../sidecar/YAMLSidecarConfigurationTest.java | 84 +++ .../cassandra/sidecar/snapshots/SnapshotUtils.java | 21 +- src/test/resources/sidecar_multiple_instances.yaml | 12 +- src/test/resources/sidecar_single_instance.yaml| 5 + .../sidecar_with_single_multiple_instances.yaml| 17 +- 43 files changed, 1330 insertions(+), 388 deletions(-) diff --git a/CHANGES.txt b/CHANGES.txt index 1c92ca5..dd7f1e1 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @
[jira] [Commented] (CASSANDRASC-47) Introduce JMX foundation in Sidecar
[ https://issues.apache.org/jira/browse/CASSANDRASC-47?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17635981#comment-17635981 ] ASF subversion and git services commented on CASSANDRASC-47: Commit 02cc6548f291528e9749a51d103463f9552f4b4e in cassandra-sidecar's branch refs/heads/trunk from Francisco Guerrero [ https://gitbox.apache.org/repos/asf?p=cassandra-sidecar.git;h=02cc654 ] CASSANDRASC-47: Introduce JMX foundation in Sidecar In this commit, we introduce the JMX foundation in Sidecar to enable the ability to communicate with the Cassandra process. This commit adds new configuration parameters to configure the a `org.apache.cassandra.sidecar.common.JmxClient`. This client is available as part of the Cassandra delegate. A new interface is introduced and exposed through the `org.apache.cassandra.sidecar.common.ICassandraAdapter`. The new interface `StorageOperations` is intended to interface with the Cassandra StorageService. This commit provides an example implementation of the `takeSnapshot` method, which is also found in the Cassandra code base. This should allow us to interact with the Cassandra process to create snapshots. A fix is required in the `CassandraSidecarDaemon` class, where the `healthCheck` runs the first time only after the configured health check frequency (millis) has passed. This causes issues in the unit tests as well as the actual execution of the service, as the `adapter` will be `null` until the first health check is performed. To fix this issue, we perform a health check right after the server successfully starts up. Additional integration tests are added for testing the JMX integration with Cassandra. In the test, we spin up a new Cassandra container using `testcontainers` and we perform validation against the StorageService in Cassandra. Co-authored-by: Doug Rohrer patch by Francisco Guerrero, Doug Rohrer; reviewed by Yifan Cai, Dinesh Joshi for CASSANDRASC-47 > Introduce JMX foundation in Sidecar > --- > > Key: CASSANDRASC-47 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-47 > Project: Sidecar for Apache Cassandra > Issue Type: Improvement > Components: Rest API >Reporter: Francisco Guerrero >Assignee: Francisco Guerrero >Priority: Normal > Labels: pull-request-available > > Currently, Sidecar supports CQL access to the Cassandra instances it manages. > However, JMX support is not available at the moment. We need to introduce the > JMX foundation in Sidecar to support additional interactions with Cassandra > instances that are not available through the CQL protocol. > This ticket is intended for introducing the JMX foundation, that can later be > used for adding new functionality to Sidecar interactions with Cassandra > through JMX. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRASC-47) Introduce JMX foundation in Sidecar
[ https://issues.apache.org/jira/browse/CASSANDRASC-47?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yifan Cai updated CASSANDRASC-47: - Fix Version/s: 1.0 Source Control Link: https://github.com/apache/cassandra-sidecar/commit/02cc6548f291528e9749a51d103463f9552f4b4e Resolution: Fixed Status: Resolved (was: Ready to Commit) > Introduce JMX foundation in Sidecar > --- > > Key: CASSANDRASC-47 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-47 > Project: Sidecar for Apache Cassandra > Issue Type: Improvement > Components: Rest API >Reporter: Francisco Guerrero >Assignee: Francisco Guerrero >Priority: Normal > Labels: pull-request-available > Fix For: 1.0 > > > Currently, Sidecar supports CQL access to the Cassandra instances it manages. > However, JMX support is not available at the moment. We need to introduce the > JMX foundation in Sidecar to support additional interactions with Cassandra > instances that are not available through the CQL protocol. > This ticket is intended for introducing the JMX foundation, that can later be > used for adding new functionality to Sidecar interactions with Cassandra > through JMX. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRASC-48) Add an endpoint that gives information about the release version & partitioner name of a node
[
https://issues.apache.org/jira/browse/CASSANDRASC-48?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17635984#comment-17635984
]
Yifan Cai commented on CASSANDRASC-48:
--
+1 on the patch!
> Add an endpoint that gives information about the release version &
> partitioner name of a node
> -
>
> Key: CASSANDRASC-48
> URL: https://issues.apache.org/jira/browse/CASSANDRASC-48
> Project: Sidecar for Apache Cassandra
> Issue Type: New Feature
> Components: Rest API
>Reporter: Jyothsna Konisa
>Assignee: Jyothsna Konisa
>Priority: Normal
> Labels: pull-request-available
>
> Add a new endpoint in sidecar that gives information about the release
> version & partitioner name of a node.
> GET /api/v1/cassandra/status
> GET /api/v1/cassandra/status?instanceId={id}
> Response
> {
> releaseVersion: "4.2-SNAPSHOT",
> partitioner: "org.apache.cassandra.dht.Murmur3Partitioner"
> }
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRASC-48) Add an endpoint that gives information about the release version & partitioner name of a node
[
https://issues.apache.org/jira/browse/CASSANDRASC-48?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17635990#comment-17635990
]
Dinesh Joshi commented on CASSANDRASC-48:
-
+1 thanks for the patch!
> Add an endpoint that gives information about the release version &
> partitioner name of a node
> -
>
> Key: CASSANDRASC-48
> URL: https://issues.apache.org/jira/browse/CASSANDRASC-48
> Project: Sidecar for Apache Cassandra
> Issue Type: New Feature
> Components: Rest API
>Reporter: Jyothsna Konisa
>Assignee: Jyothsna Konisa
>Priority: Normal
> Labels: pull-request-available
>
> Add a new endpoint in sidecar that gives information about the release
> version & partitioner name of a node.
> GET /api/v1/cassandra/status
> GET /api/v1/cassandra/status?instanceId={id}
> Response
> {
> releaseVersion: "4.2-SNAPSHOT",
> partitioner: "org.apache.cassandra.dht.Murmur3Partitioner"
> }
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17477) -dc option for repair, prevents incremental repairs
[
https://issues.apache.org/jira/browse/CASSANDRA-17477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17635994#comment-17635994
]
n.v.harikrishna commented on CASSANDRA-17477:
-
Sorry for taking so long to given an update.
As per the code here
[https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/service/ActiveRepairService.java#L585]
{noformat}
/**
* we only want to set repairedAt for incremental repairs including all
replicas for a token range. For non-global
* incremental repairs, forced incremental repairs, and full repairs, the
UNREPAIRED_SSTABLE value will prevent
* sstables from being promoted to repaired or preserve the
repairedAt/pendingRepair values, respectively.
*/
static long getRepairedAt(RepairOption options, boolean force)
{
// we only want to set repairedAt for incremental repairs including all
replicas for a token range. For non-global incremental repairs, full repairs,
the UNREPAIRED_SSTABLE value will prevent
// sstables from being promoted to repaired or preserve the
repairedAt/pendingRepair values, respectively. For forced repairs, repairedAt
time is only set to UNREPAIRED_SSTABLE if we actually
// end up skipping replicas
if (options.isIncremental() && options.isGlobal() && !force)
{
return currentTimeMillis();
}
else
{
return ActiveRepairService.UNREPAIRED_SSTABLE;
}
}{noformat}
and RepairOption.isGlobal()
{noformat}
public boolean isGlobal()
{
return dataCenters.isEmpty() && hosts.isEmpty();
}
{noformat}
it is behaving as expected as the data centre is explicitly specified in the
first case.
> -dc option for repair, prevents incremental repairs
> ---
>
> Key: CASSANDRA-17477
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17477
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Repair
>Reporter: Pedro Gordo
>Assignee: n.v.harikrishna
>Priority: Normal
> Fix For: 4.0.x, 4.x
>
>
> By default running `{*}nodetool repair{*}` should trigger incremental
> repairs, but this does not happen if you use the `{*}-dc{*}` flag, even
> though the repair summary says `{*}incremental: true{*}`.
> You can replicate the issue with the following commands:
> {code:bash}
> ccm create test-incremental-repairs -v 4.0.1 -n 3 -s
> ccm node1 cqlsh -e "CREATE KEYSPACE keyspace1 WITH replication = {'class':
> 'NetworkTopologyStrategy', 'datacenter1': 2 };"
> ccm stress write
> ccm node1 nodetool "repair keyspace1 standard1 -dc datacenter1"
> find ~/.ccm/test-incremental-repairs/*/data0/keyspace1/standard1* -name
> *Data.db -exec /bin/sstablemetadata {} \; | grep Repaired
> ccm node1 nodetool "repair keyspace1 standard1"
> find ~/.ccm/test-incremental-repairs/*/data0/keyspace1/standard1* -name
> *Data.db -exec /bin/sstablemetadata {} \; | grep Repaired
> {code}
> You'll notice that the output for the first `{*}find{*}` command will all be
> `{*}Repaired at: 0{*}`, but the second `{*}find{*}` command will give you
> results like `{*}Repaired at: 1648044754464 (03/23/2022 14:12:34){*}`.
> At the same time, both `{*}nodetool repair{*}` commands will output like the
> following:
> {code:bash}
> [2022-03-23 15:15:52,500] Starting repair command #2
> (20f12190-aabc-11ec-a3d4-e9e5a941ef6c), repairing keyspace keyspace1 with
> repair options (parallelism: parallel, primary range: false, incremental:
> true, job threads: 1, ColumnFamilies: [standard1], dataCenters:
> [datacenter1], hosts: [], previewKind: NONE, # of ranges: 2, pull repair:
> false, force repair: false, optimise streams: false, ignore unreplicated
> keyspaces: false)
> {code}
> Indicating `{*}incremental: true{*}` for both of them.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 01/01: Merge branch 'cassandra-4.1' into trunk
This is an automated email from the ASF dual-hosted git repository. edimitrova pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git commit fb09a5c1bbd73ddf7f5891fbbbc0bffe53cbee56 Merge: 3860a90c5f bc16752bd7 Author: Ekaterina Dimitrova AuthorDate: Fri Nov 18 15:44:30 2022 -0500 Merge branch 'cassandra-4.1' into trunk doc/modules/cassandra/nav.adoc | 12 +- .../cassandra/pages/operating/virtualtables.adoc | 410 + 2 files changed, 420 insertions(+), 2 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated (3860a90c5f -> fb09a5c1bb)
This is an automated email from the ASF dual-hosted git repository.
edimitrova pushed a change to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra.git
from 3860a90c5f Change shebangs of Python scripts to resolve Python 3 from
env command
add bc16752bd7 Restore Virtual Tables page, and update nav for new pages
patch by Ekaterina Dimitrova; reviewed by Mick Semb Wever for CASSANDRA-17976
new fb09a5c1bb Merge branch 'cassandra-4.1' into trunk
The 1 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails. The revisions
listed as "add" were already present in the repository and have only
been added to this reference.
Summary of changes:
doc/modules/cassandra/nav.adoc | 12 +-
.../pages/{new => operating}/virtualtables.adoc| 157 -
2 files changed, 35 insertions(+), 134 deletions(-)
copy doc/modules/cassandra/pages/{new => operating}/virtualtables.adoc (77%)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-4.1 updated (d6822c45ae -> bc16752bd7)
This is an automated email from the ASF dual-hosted git repository.
edimitrova pushed a change to branch cassandra-4.1
in repository https://gitbox.apache.org/repos/asf/cassandra.git
from d6822c45ae Prepare debian changelog for 4.1-rc1
add bc16752bd7 Restore Virtual Tables page, and update nav for new pages
patch by Ekaterina Dimitrova; reviewed by Mick Semb Wever for CASSANDRA-17976
No new revisions were added by this update.
Summary of changes:
doc/modules/cassandra/nav.adoc | 12 +-
.../pages/{new => operating}/virtualtables.adoc| 157 -
2 files changed, 35 insertions(+), 134 deletions(-)
copy doc/modules/cassandra/pages/{new => operating}/virtualtables.adoc (77%)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17976) WEBSITE - Update What's New Page for 4.1 and trunk
[ https://issues.apache.org/jira/browse/CASSANDRA-17976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17636036#comment-17636036 ] Ekaterina Dimitrova commented on CASSANDRA-17976: - Committed to both branches, I did verified the menu and the Virtual tables page manually locally in my IDE that everything looks as expected. To https://github.com/apache/cassandra.git [d6822c45ae..bc16752bd7|https://github.com/apache/cassandra/commit/bc16752bd73356364cdf990a093521771b5e488a] cassandra-4.1 -> cassandra-4.1 [3860a90c5f..fb09a5c1bb|https://github.com/apache/cassandra/commit/fb09a5c1bbd73ddf7f5891fbbbc0bffe53cbee56] trunk -> trunk > WEBSITE - Update What's New Page for 4.1 and trunk > -- > > Key: CASSANDRA-17976 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17976 > Project: Cassandra > Issue Type: Task > Components: Documentation/Website >Reporter: Ekaterina Dimitrova >Assignee: Michael Semb Wever >Priority: Low > Fix For: 4.1-beta2, 4.1, 4.2 > > Attachments: Screenshot 2022-11-02 at 22.22.48.png, Screenshot > 2022-11-02 at 22.40.13.png, c17976-01-doc-whats_new-4.1.png, > c17976-02-doc-whats_new-trunk.png > > > [https://cassandra.apache.org/doc/4.1/cassandra/new/index.html] > The page still says 4.0 and lists 4.0 new developments. > We need to point to 4.1 and list latest developments blog posts, docs; > probably we can also link NEWS.txt and CHANGES.txt -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17832) Change bin/cqlsh.py shebang to use PATH with env prefix
[
https://issues.apache.org/jira/browse/CASSANDRA-17832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17636042#comment-17636042
]
Brad Schoening commented on CASSANDRA-17832:
Great.
BTW, it seems a separate Jira could look at simplifying the shell script
'cqlsh' to also use /usr/bin/env instead of its current homebrew approach to
finding the python interpreter.
It's true that a shebang in cqlsh.py is sort of belts-n-suspenders, but it
simplifies running the script directly by exec-ing the .py file and ensures
that you picked up the intended version of cqlsh.py. I often run it that way
when testing changes.
> Change bin/cqlsh.py shebang to use PATH with env prefix
> ---
>
> Key: CASSANDRA-17832
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17832
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Brad Schoening
>Assignee: Brad Schoening
>Priority: Low
> Fix For: 4.2
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> For cqlsh.py this:
> #!/usr/bin/env python
> is preferable to the current hard coded /usr/bin/python3 which doesn't take
> into account the python interpreter preferences in the users PATH.
> '{{{}env{}}}' is a system binary in {{/usr/bin}} that searches {{$PATH}} for
> strings containing the provided argument and returns the first instance it
> finds. In the above syntax, {{env}} will search for the first instance of
> {{python}} in {{$PATH}} and return it.
> This is aligned with the recommendations in
> [https://peps.python.org/pep-0394/]
> For example, on a MacOS Monterey 12.5.1 with both xcode python and brew
> installed python:
>
> {code:java}
> % /usr/bin/python3 --version
> Python 3.8.9. (xcode python version)
> % /usr/bin/env python --version
> Python 3.10.6. (brew python version)
> % python --version
> Python 3.10.6. (default)
> {code}
> Thus, /usr/bin/python3 doesn't run the expected default python version
> Even the official Python tutorial uses the /usr/bin/env form of shebang:
> [https://docs.python.org/3/tutorial/interpreter.html]
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-sidecar] branch trunk updated: CASSANDRASC-48: Adding new endpoint that gives information about the release version & partitioner name of a node
This is an automated email from the ASF dual-hosted git repository.
ycai pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra-sidecar.git
The following commit(s) were added to refs/heads/trunk by this push:
new 252d983 CASSANDRASC-48: Adding new endpoint that gives information
about the release version & partitioner name of a node
252d983 is described below
commit 252d983cc11af3dee3588a1c328eac7a080bd462
Author: jkonisa
AuthorDate: Thu Nov 10 12:06:09 2022 -0800
CASSANDRASC-48: Adding new endpoint that gives information about the
release version & partitioner name of a node
Adds new APIs
GET /api/v1/cassandra/status
- Returns the NodeStatus with release version & partitioner info of the
node receiving the request
GET /api/v1/cassandra/status?instanceId={id}
- Returs the NodeStatus with release version & partitioner info of a
given instanceId
patch by Jyothsna Konisa; reviewed by Dinesh Joshi, Francisco Guerrero,
Yifan Cai for CASSANDRASC-48
---
CHANGES.txt| 1 +
build.gradle | 1 +
.../sidecar/cassandra40/Cassandra40Factory.java| 7 +-
.../sidecar/common/CassandraAdapterDelegate.java | 55 +
.../sidecar/common/ICassandraAdapter.java | 4 +-
.../cassandra/sidecar/common/NodeSettings.java | 57 +
.../cassandra/sidecar/common/NodeStatus.java | 28 -
.../org/apache/cassandra/sidecar/MainModule.java | 5 +-
.../sidecar/routes/CassandraHealthService.java | 10 +-
.../sidecar/routes/CassandraSettingsService.java | 84 +
.../sidecar/utils/InstanceMetadataFetcher.java | 16 +++
.../sidecar/AbstractHealthServiceTest.java | 5 +-
.../org/apache/cassandra/sidecar/TestModule.java | 5 +
.../routes/CassandraSettingsServiceTest.java | 135 +
14 files changed, 342 insertions(+), 71 deletions(-)
diff --git a/CHANGES.txt b/CHANGES.txt
index dd7f1e1..aec5dc7 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,5 +1,6 @@
1.0.0
-
+ * Add an endpoint that gives information about the release version &
partitioner name of a node (CASSANDRASC-48)
* Introduce JMX foundation in Sidecar (CASSANDRASC-47)
* Delegate methods to the RateLimiter (CASSANDRASC-45)
* Add Schema API (CASSANDRASC-43)
diff --git a/build.gradle b/build.gradle
index c81c4c4..d959335 100644
--- a/build.gradle
+++ b/build.gradle
@@ -108,6 +108,7 @@ dependencies {
implementation('com.google.inject:guice:4.2.2')
implementation('io.swagger.core.v3:swagger-jaxrs2:2.1.0')
implementation("org.jboss.resteasy:resteasy-vertx:4.7.4.Final")
+implementation('org.jboss.resteasy:resteasy-jackson2-provider:4.7.4.Final')
implementation(group: 'org.jboss.spec.javax.servlet', name:
'jboss-servlet-api_4.0_spec', version: '2.0.0.Final')
implementation('org.jetbrains:annotations:23.0.0')
diff --git
a/cassandra40/src/main/java/org/apache/cassandra/sidecar/cassandra40/Cassandra40Factory.java
b/cassandra40/src/main/java/org/apache/cassandra/sidecar/cassandra40/Cassandra40Factory.java
index be98d32..b62b80a 100644
---
a/cassandra40/src/main/java/org/apache/cassandra/sidecar/cassandra40/Cassandra40Factory.java
+++
b/cassandra40/src/main/java/org/apache/cassandra/sidecar/cassandra40/Cassandra40Factory.java
@@ -18,14 +18,12 @@
package org.apache.cassandra.sidecar.cassandra40;
-import java.util.List;
-
import org.apache.cassandra.sidecar.common.CQLSession;
import org.apache.cassandra.sidecar.common.ICassandraAdapter;
import org.apache.cassandra.sidecar.common.ICassandraFactory;
import org.apache.cassandra.sidecar.common.JmxClient;
import org.apache.cassandra.sidecar.common.MinimumVersion;
-import org.apache.cassandra.sidecar.common.NodeStatus;
+import org.apache.cassandra.sidecar.common.NodeSettings;
import org.apache.cassandra.sidecar.common.StorageOperations;
/**
@@ -47,8 +45,9 @@ public class Cassandra40Factory implements ICassandraFactory
{
return new ICassandraAdapter()
{
+
@Override
-public List getStatus()
+public NodeSettings getSettings()
{
return null;
}
diff --git
a/common/src/main/java/org/apache/cassandra/sidecar/common/CassandraAdapterDelegate.java
b/common/src/main/java/org/apache/cassandra/sidecar/common/CassandraAdapterDelegate.java
index 0407a4d..03d0049 100644
---
a/common/src/main/java/org/apache/cassandra/sidecar/common/CassandraAdapterDelegate.java
+++
b/common/src/main/java/org/apache/cassandra/sidecar/common/CassandraAdapterDelegate.java
@@ -18,17 +18,19 @@
package org.apache.cassandra.sidecar.common;
-import java.util.List;
import java.util.concurrent.atomic.AtomicBoolean;
+import java.util.concurrent.atomic.AtomicReference;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import c
[jira] [Commented] (CASSANDRASC-48) Add an endpoint that gives information about the release version & partitioner name of a node
[
https://issues.apache.org/jira/browse/CASSANDRASC-48?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17636046#comment-17636046
]
ASF subversion and git services commented on CASSANDRASC-48:
Commit 252d983cc11af3dee3588a1c328eac7a080bd462 in cassandra-sidecar's branch
refs/heads/trunk from jkonisa
[ https://gitbox.apache.org/repos/asf?p=cassandra-sidecar.git;h=252d983 ]
CASSANDRASC-48: Adding new endpoint that gives information about the release
version & partitioner name of a node
Adds new APIs
GET /api/v1/cassandra/status
- Returns the NodeStatus with release version & partitioner info of the node
receiving the request
GET /api/v1/cassandra/status?instanceId={id}
- Returs the NodeStatus with release version & partitioner info of a given
instanceId
patch by Jyothsna Konisa; reviewed by Dinesh Joshi, Francisco Guerrero, Yifan
Cai for CASSANDRASC-48
> Add an endpoint that gives information about the release version &
> partitioner name of a node
> -
>
> Key: CASSANDRASC-48
> URL: https://issues.apache.org/jira/browse/CASSANDRASC-48
> Project: Sidecar for Apache Cassandra
> Issue Type: New Feature
> Components: Rest API
>Reporter: Jyothsna Konisa
>Assignee: Jyothsna Konisa
>Priority: Normal
> Labels: pull-request-available
>
> Add a new endpoint in sidecar that gives information about the release
> version & partitioner name of a node.
> GET /api/v1/cassandra/status
> GET /api/v1/cassandra/status?instanceId={id}
> Response
> {
> releaseVersion: "4.2-SNAPSHOT",
> partitioner: "org.apache.cassandra.dht.Murmur3Partitioner"
> }
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRASC-48) Add an endpoint that gives information about the release version & partitioner name of a node
[
https://issues.apache.org/jira/browse/CASSANDRASC-48?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jyothsna Konisa updated CASSANDRASC-48:
---
Authors: Jyothsna Konisa
Test and Documentation Plan: Added test cases to test the new endpoints
Status: Patch Available (was: Open)
> Add an endpoint that gives information about the release version &
> partitioner name of a node
> -
>
> Key: CASSANDRASC-48
> URL: https://issues.apache.org/jira/browse/CASSANDRASC-48
> Project: Sidecar for Apache Cassandra
> Issue Type: New Feature
> Components: Rest API
>Reporter: Jyothsna Konisa
>Assignee: Jyothsna Konisa
>Priority: Normal
> Labels: pull-request-available
>
> Add a new endpoint in sidecar that gives information about the release
> version & partitioner name of a node.
> GET /api/v1/cassandra/status
> GET /api/v1/cassandra/status?instanceId={id}
> Response
> {
> releaseVersion: "4.2-SNAPSHOT",
> partitioner: "org.apache.cassandra.dht.Murmur3Partitioner"
> }
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRASC-48) Add an endpoint that gives information about the release version & partitioner name of a node
[
https://issues.apache.org/jira/browse/CASSANDRASC-48?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yifan Cai updated CASSANDRASC-48:
-
Status: Ready to Commit (was: Review In Progress)
> Add an endpoint that gives information about the release version &
> partitioner name of a node
> -
>
> Key: CASSANDRASC-48
> URL: https://issues.apache.org/jira/browse/CASSANDRASC-48
> Project: Sidecar for Apache Cassandra
> Issue Type: New Feature
> Components: Rest API
>Reporter: Jyothsna Konisa
>Assignee: Jyothsna Konisa
>Priority: Normal
> Labels: pull-request-available
>
> Add a new endpoint in sidecar that gives information about the release
> version & partitioner name of a node.
> GET /api/v1/cassandra/status
> GET /api/v1/cassandra/status?instanceId={id}
> Response
> {
> releaseVersion: "4.2-SNAPSHOT",
> partitioner: "org.apache.cassandra.dht.Murmur3Partitioner"
> }
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRASC-48) Add an endpoint that gives information about the release version & partitioner name of a node
[
https://issues.apache.org/jira/browse/CASSANDRASC-48?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yifan Cai updated CASSANDRASC-48:
-
Status: Review In Progress (was: Patch Available)
> Add an endpoint that gives information about the release version &
> partitioner name of a node
> -
>
> Key: CASSANDRASC-48
> URL: https://issues.apache.org/jira/browse/CASSANDRASC-48
> Project: Sidecar for Apache Cassandra
> Issue Type: New Feature
> Components: Rest API
>Reporter: Jyothsna Konisa
>Assignee: Jyothsna Konisa
>Priority: Normal
> Labels: pull-request-available
>
> Add a new endpoint in sidecar that gives information about the release
> version & partitioner name of a node.
> GET /api/v1/cassandra/status
> GET /api/v1/cassandra/status?instanceId={id}
> Response
> {
> releaseVersion: "4.2-SNAPSHOT",
> partitioner: "org.apache.cassandra.dht.Murmur3Partitioner"
> }
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRASC-48) Add an endpoint that gives information about the release version & partitioner name of a node
[
https://issues.apache.org/jira/browse/CASSANDRASC-48?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yifan Cai updated CASSANDRASC-48:
-
Fix Version/s: 1.0
Source Control Link:
https://github.com/apache/cassandra-sidecar/commit/252d983cc11af3dee3588a1c328eac7a080bd462
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
> Add an endpoint that gives information about the release version &
> partitioner name of a node
> -
>
> Key: CASSANDRASC-48
> URL: https://issues.apache.org/jira/browse/CASSANDRASC-48
> Project: Sidecar for Apache Cassandra
> Issue Type: New Feature
> Components: Rest API
>Reporter: Jyothsna Konisa
>Assignee: Jyothsna Konisa
>Priority: Normal
> Labels: pull-request-available
> Fix For: 1.0
>
>
> Add a new endpoint in sidecar that gives information about the release
> version & partitioner name of a node.
> GET /api/v1/cassandra/status
> GET /api/v1/cassandra/status?instanceId={id}
> Response
> {
> releaseVersion: "4.2-SNAPSHOT",
> partitioner: "org.apache.cassandra.dht.Murmur3Partitioner"
> }
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17918) DESCRIBE output does not quote column names using reserved keywords
[
https://issues.apache.org/jira/browse/CASSANDRA-17918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17636060#comment-17636060
]
Bernardo Botella Corbi commented on CASSANDRA-17918:
[~yifanc] New revision updated.
> DESCRIBE output does not quote column names using reserved keywords
> ---
>
> Key: CASSANDRA-17918
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17918
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/CQL
>Reporter: Yifan Cai
>Assignee: Bernardo Botella Corbi
>Priority: Normal
> Fix For: 4.0.x, 4.1.x
>
>
> The DESCRIBE output of the column names that using reserved keywords are not
> quoted for UDTs. The following test reproduces. Reading the code, it looks
> like that the such columns names are not quoted in materialized view, UDF and
> user defined aggregation.
> The impact of the bug is that schema described cannot be imported due to the
> usage of reserved keywords as column names.
>
> {code:java}
> @Test
> public void testUsingReservedInCreateType() throws Throwable
> {
> String type = createType(KEYSPACE_PER_TEST, "CREATE TYPE %s
> (\"token\" text, \"desc\" text);");
> assertRowsNet(executeDescribeNet(KEYSPACE_PER_TEST, "DESCRIBE TYPE " + type),
> row(KEYSPACE_PER_TEST, "type", type, "CREATE TYPE " +
> KEYSPACE_PER_TEST + "." + type + " (\n" +
> " \"token\" text,\n" +
> " \"desc\" text\n" +
> ");"));
> } {code}
> +Additional information for newcomers:+
> * Unit tests for DESCRIBE statements are in {{DescribeStatementTest}}
> * The statement implementation is in {{DescribeStatement and fetch the
> create statement from the different schema element using
> SchemaElement.toCqlString}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18060) Add aggregation scalar functions on collections
[
https://issues.apache.org/jira/browse/CASSANDRA-18060?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andres de la Peña updated CASSANDRA-18060:
--
Summary: Add aggregation scalar functions on collections (was: Add
aggregation scalar functions on collections, tuples and UDTs)
> Add aggregation scalar functions on collections
> ---
>
> Key: CASSANDRA-18060
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18060
> Project: Cassandra
> Issue Type: New Feature
> Components: CQL/Semantics
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
>
> The new mechanism for dynamically building native functions introduced by
> CASSANDRA-17811 can be used to provide within-collection aggregation
> functions. We can use that mechanism to add new CQL functions to get:
> * The number of items in a collection.
> * The max/min items of a collection.
> * The sum/avg of the items of a numeric collection.
> * The keys or the values of a map.
> For example:
> {code:java}
> CREATE TABLE k.t (k int PRIMARY KEY, l list, m map);
> INSERT INTO t(k, l, m) VALUES (0, [1, 2, 3], {1:10, 2:20, 3:30});
> > SELECT map_keys(m), map_values(m) FROM t;
> system.map_keys(m) | system.map_values(m)
> +--
> {1, 2, 3} | [10, 20, 30]
> > SELECT collection_count(m), collection_count(l) FROM t;
> system.collection_count(m) | system.collection_count(l)
> +
> 3 | 3
> > SELECT collection_min(l), collection_max(l) FROM t;
> system.collection_min(l) | system.collection_max(l)
> --+--
> 1 |3
> > SELECT collection_sum(l), collection_avg(l) FROM t;
> system.collection_sum(l) | system.collection_avg(l)
> --+--
> 6 |2
> {code}
> Note that this type of aggregation is different from the kind of aggregation
> provided by {{min}}, {{max}}, {{sum}} and {{avg}}, which aggregate entire
> collections across rows. Here we only aggregate the items of a collection row
> per row.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18060) Add aggregation scalar functions on collections
[
https://issues.apache.org/jira/browse/CASSANDRA-18060?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andres de la Peña updated CASSANDRA-18060:
--
Change Category: Semantic
Complexity: Normal
Status: Open (was: Triage Needed)
> Add aggregation scalar functions on collections
> ---
>
> Key: CASSANDRA-18060
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18060
> Project: Cassandra
> Issue Type: New Feature
> Components: CQL/Semantics
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The new mechanism for dynamically building native functions introduced by
> CASSANDRA-17811 can be used to provide within-collection aggregation
> functions. We can use that mechanism to add new CQL functions to get:
> * The number of items in a collection.
> * The max/min items of a collection.
> * The sum/avg of the items of a numeric collection.
> * The keys or the values of a map.
> For example:
> {code:java}
> CREATE TABLE k.t (k int PRIMARY KEY, l list, m map);
> INSERT INTO t(k, l, m) VALUES (0, [1, 2, 3], {1:10, 2:20, 3:30});
> > SELECT map_keys(m), map_values(m) FROM t;
> system.map_keys(m) | system.map_values(m)
> +--
> {1, 2, 3} | [10, 20, 30]
> > SELECT collection_count(m), collection_count(l) FROM t;
> system.collection_count(m) | system.collection_count(l)
> +
> 3 | 3
> > SELECT collection_min(l), collection_max(l) FROM t;
> system.collection_min(l) | system.collection_max(l)
> --+--
> 1 |3
> > SELECT collection_sum(l), collection_avg(l) FROM t;
> system.collection_sum(l) | system.collection_avg(l)
> --+--
> 6 |2
> {code}
> Note that this type of aggregation is different from the kind of aggregation
> provided by {{min}}, {{max}}, {{sum}} and {{avg}}, which aggregate entire
> collections across rows. Here we only aggregate the items of a collection row
> per row.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18060) Add aggregation scalar functions on collections
[
https://issues.apache.org/jira/browse/CASSANDRA-18060?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andres de la Peña updated CASSANDRA-18060:
--
Source Control Link: https://github.com/apache/cassandra/pull/2024
> Add aggregation scalar functions on collections
> ---
>
> Key: CASSANDRA-18060
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18060
> Project: Cassandra
> Issue Type: New Feature
> Components: CQL/Semantics
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The new mechanism for dynamically building native functions introduced by
> CASSANDRA-17811 can be used to provide within-collection aggregation
> functions. We can use that mechanism to add new CQL functions to get:
> * The number of items in a collection.
> * The max/min items of a collection.
> * The sum/avg of the items of a numeric collection.
> * The keys or the values of a map.
> For example:
> {code:java}
> CREATE TABLE k.t (k int PRIMARY KEY, l list, m map);
> INSERT INTO t(k, l, m) VALUES (0, [1, 2, 3], {1:10, 2:20, 3:30});
> > SELECT map_keys(m), map_values(m) FROM t;
> system.map_keys(m) | system.map_values(m)
> +--
> {1, 2, 3} | [10, 20, 30]
> > SELECT collection_count(m), collection_count(l) FROM t;
> system.collection_count(m) | system.collection_count(l)
> +
> 3 | 3
> > SELECT collection_min(l), collection_max(l) FROM t;
> system.collection_min(l) | system.collection_max(l)
> --+--
> 1 |3
> > SELECT collection_sum(l), collection_avg(l) FROM t;
> system.collection_sum(l) | system.collection_avg(l)
> --+--
> 6 |2
> {code}
> Note that this type of aggregation is different from the kind of aggregation
> provided by {{min}}, {{max}}, {{sum}} and {{avg}}, which aggregate entire
> collections across rows. Here we only aggregate the items of a collection row
> per row.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18060) Add aggregation scalar functions on collections
[
https://issues.apache.org/jira/browse/CASSANDRA-18060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17636066#comment-17636066
]
Andres de la Peña commented on CASSANDRA-18060:
---
Here is the patch, and CI is running:
||PR||CI||
|[trunk|https://github.com/apache/cassandra/pull/2024]|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/2508/workflows/92f054d7-9386-498f-9ba4-330181cd4782]
[j11|https://app.circleci.com/pipelines/github/adelapena/cassandra/2508/workflows/8a0838e8-ffbb-424d-a572-3770f9a41632]|
Differently to [the
prototype|https://github.com/apache/cassandra/compare/trunk...adelapena:cassandra:17811-trunk-collections?expand=1]
mentioned during CASSANDRA-17811, the proposed PR uses the existing
aggregation functions available at {{AggregateFcts}} as the underlying
implementation of {{{}collection_min{}}}, {{{}collection_max{}}},
{{collection_sum}} and {{{}collection_avg{}}}. That way we avoid code
duplication and make sure that the functions are consistent.
> Add aggregation scalar functions on collections
> ---
>
> Key: CASSANDRA-18060
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18060
> Project: Cassandra
> Issue Type: New Feature
> Components: CQL/Semantics
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The new mechanism for dynamically building native functions introduced by
> CASSANDRA-17811 can be used to provide within-collection aggregation
> functions. We can use that mechanism to add new CQL functions to get:
> * The number of items in a collection.
> * The max/min items of a collection.
> * The sum/avg of the items of a numeric collection.
> * The keys or the values of a map.
> For example:
> {code:java}
> CREATE TABLE k.t (k int PRIMARY KEY, l list, m map);
> INSERT INTO t(k, l, m) VALUES (0, [1, 2, 3], {1:10, 2:20, 3:30});
> > SELECT map_keys(m), map_values(m) FROM t;
> system.map_keys(m) | system.map_values(m)
> +--
> {1, 2, 3} | [10, 20, 30]
> > SELECT collection_count(m), collection_count(l) FROM t;
> system.collection_count(m) | system.collection_count(l)
> +
> 3 | 3
> > SELECT collection_min(l), collection_max(l) FROM t;
> system.collection_min(l) | system.collection_max(l)
> --+--
> 1 |3
> > SELECT collection_sum(l), collection_avg(l) FROM t;
> system.collection_sum(l) | system.collection_avg(l)
> --+--
> 6 |2
> {code}
> Note that this type of aggregation is different from the kind of aggregation
> provided by {{min}}, {{max}}, {{sum}} and {{avg}}, which aggregate entire
> collections across rows. Here we only aggregate the items of a collection row
> per row.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18060) Add aggregation scalar functions on collections
[
https://issues.apache.org/jira/browse/CASSANDRA-18060?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andres de la Peña updated CASSANDRA-18060:
--
Test and Documentation Plan:
||PR||CI||
|[trunk|https://github.com/apache/cassandra/pull/2024]|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/2508/workflows/92f054d7-9386-498f-9ba4-330181cd4782]
[j11|https://app.circleci.com/pipelines/github/adelapena/cassandra/2508/workflows/8a0838e8-ffbb-424d-a572-3770f9a41632]|
Status: Patch Available (was: In Progress)
> Add aggregation scalar functions on collections
> ---
>
> Key: CASSANDRA-18060
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18060
> Project: Cassandra
> Issue Type: New Feature
> Components: CQL/Semantics
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The new mechanism for dynamically building native functions introduced by
> CASSANDRA-17811 can be used to provide within-collection aggregation
> functions. We can use that mechanism to add new CQL functions to get:
> * The number of items in a collection.
> * The max/min items of a collection.
> * The sum/avg of the items of a numeric collection.
> * The keys or the values of a map.
> For example:
> {code:java}
> CREATE TABLE k.t (k int PRIMARY KEY, l list, m map);
> INSERT INTO t(k, l, m) VALUES (0, [1, 2, 3], {1:10, 2:20, 3:30});
> > SELECT map_keys(m), map_values(m) FROM t;
> system.map_keys(m) | system.map_values(m)
> +--
> {1, 2, 3} | [10, 20, 30]
> > SELECT collection_count(m), collection_count(l) FROM t;
> system.collection_count(m) | system.collection_count(l)
> +
> 3 | 3
> > SELECT collection_min(l), collection_max(l) FROM t;
> system.collection_min(l) | system.collection_max(l)
> --+--
> 1 |3
> > SELECT collection_sum(l), collection_avg(l) FROM t;
> system.collection_sum(l) | system.collection_avg(l)
> --+--
> 6 |2
> {code}
> Note that this type of aggregation is different from the kind of aggregation
> provided by {{min}}, {{max}}, {{sum}} and {{avg}}, which aggregate entire
> collections across rows. Here we only aggregate the items of a collection row
> per row.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18060) Add aggregation scalar functions on collections
[
https://issues.apache.org/jira/browse/CASSANDRA-18060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17636066#comment-17636066
]
Andres de la Peña edited comment on CASSANDRA-18060 at 11/18/22 11:00 PM:
--
Here is the patch, and CI is running:
||PR||CI||
|[trunk|https://github.com/apache/cassandra/pull/2024]|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/2508/workflows/92f054d7-9386-498f-9ba4-330181cd4782]
[j11|https://app.circleci.com/pipelines/github/adelapena/cassandra/2508/workflows/8a0838e8-ffbb-424d-a572-3770f9a41632]|
Differently to [the
prototype|https://github.com/apache/cassandra/compare/trunk...adelapena:cassandra:17811-trunk-collections?expand=1]
mentioned during CASSANDRA-17811, the proposed PR uses the existing
aggregation functions available at {{AggregateFcts}} as the underlying
implementation of {{{}collection_min{}}}, {{{}collection_max{}}},
{{collection_sum}} and {{{}collection_avg{}}}. That way we avoid code
duplication and make sure that the functions are consistent. However, that
consistency means that we inherit the design decisions taken for those
functions. The more remarkable ones IMO are
* {{sum}} and {{collection_sum}} return a value of the same type as the added
values, so any numeric value but {{decimal}} and {{varint}} can overflow.
was (Author: adelapena):
Here is the patch, and CI is running:
||PR||CI||
|[trunk|https://github.com/apache/cassandra/pull/2024]|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/2508/workflows/92f054d7-9386-498f-9ba4-330181cd4782]
[j11|https://app.circleci.com/pipelines/github/adelapena/cassandra/2508/workflows/8a0838e8-ffbb-424d-a572-3770f9a41632]|
Differently to [the
prototype|https://github.com/apache/cassandra/compare/trunk...adelapena:cassandra:17811-trunk-collections?expand=1]
mentioned during CASSANDRA-17811, the proposed PR uses the existing
aggregation functions available at {{AggregateFcts}} as the underlying
implementation of {{{}collection_min{}}}, {{{}collection_max{}}},
{{collection_sum}} and {{{}collection_avg{}}}. That way we avoid code
duplication and make sure that the functions are consistent.
> Add aggregation scalar functions on collections
> ---
>
> Key: CASSANDRA-18060
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18060
> Project: Cassandra
> Issue Type: New Feature
> Components: CQL/Semantics
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The new mechanism for dynamically building native functions introduced by
> CASSANDRA-17811 can be used to provide within-collection aggregation
> functions. We can use that mechanism to add new CQL functions to get:
> * The number of items in a collection.
> * The max/min items of a collection.
> * The sum/avg of the items of a numeric collection.
> * The keys or the values of a map.
> For example:
> {code:java}
> CREATE TABLE k.t (k int PRIMARY KEY, l list, m map);
> INSERT INTO t(k, l, m) VALUES (0, [1, 2, 3], {1:10, 2:20, 3:30});
> > SELECT map_keys(m), map_values(m) FROM t;
> system.map_keys(m) | system.map_values(m)
> +--
> {1, 2, 3} | [10, 20, 30]
> > SELECT collection_count(m), collection_count(l) FROM t;
> system.collection_count(m) | system.collection_count(l)
> +
> 3 | 3
> > SELECT collection_min(l), collection_max(l) FROM t;
> system.collection_min(l) | system.collection_max(l)
> --+--
> 1 |3
> > SELECT collection_sum(l), collection_avg(l) FROM t;
> system.collection_sum(l) | system.collection_avg(l)
> --+--
> 6 |2
> {code}
> Note that this type of aggregation is different from the kind of aggregation
> provided by {{min}}, {{max}}, {{sum}} and {{avg}}, which aggregate entire
> collections across rows. Here we only aggregate the items of a collection row
> per row.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18060) Add aggregation scalar functions on collections
[
https://issues.apache.org/jira/browse/CASSANDRA-18060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17636066#comment-17636066
]
Andres de la Peña edited comment on CASSANDRA-18060 at 11/18/22 11:06 PM:
--
Here is the patch, and CI is running:
||PR||CI||
|[trunk|https://github.com/apache/cassandra/pull/2024]|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/2508/workflows/92f054d7-9386-498f-9ba4-330181cd4782]
[j11|https://app.circleci.com/pipelines/github/adelapena/cassandra/2508/workflows/8a0838e8-ffbb-424d-a572-3770f9a41632]|
Differently to [the
prototype|https://github.com/apache/cassandra/compare/trunk...adelapena:cassandra:17811-trunk-collections?expand=1]
mentioned during CASSANDRA-17811, the proposed PR uses the existing
aggregation functions available at {{AggregateFcts}} as the underlying
implementation of {{{}collection_min{}}}, {{{}collection_max{}}},
{{collection_sum}} and {{{}collection_avg{}}}. That way we avoid code
duplication and make sure that the functions are consistent. However, that
consistency means that we inherit the design decisions taken for those
functions. The more remarkable ones IMO are
* {{sum}} and {{collection_sum}} return a value of the same type as the added
values, so any numeric value but {{decimal}} and {{varint}} can overflow.
* {{avg}} and {{collection_avg}} return a value of the same type as the input
value, so for example the average of integers 1 and 2 is 1, instead of 1.5.
* {{avg}} and {{collection_avg}} return 0 for an empty list of values, instead
of the more correct {{{}NaN{}}}.
I guess that we are unhappy with those behaviours we could have followup
tickets to try to improve them in both across-rows and across-collections-items
functions.
was (Author: adelapena):
Here is the patch, and CI is running:
||PR||CI||
|[trunk|https://github.com/apache/cassandra/pull/2024]|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/2508/workflows/92f054d7-9386-498f-9ba4-330181cd4782]
[j11|https://app.circleci.com/pipelines/github/adelapena/cassandra/2508/workflows/8a0838e8-ffbb-424d-a572-3770f9a41632]|
Differently to [the
prototype|https://github.com/apache/cassandra/compare/trunk...adelapena:cassandra:17811-trunk-collections?expand=1]
mentioned during CASSANDRA-17811, the proposed PR uses the existing
aggregation functions available at {{AggregateFcts}} as the underlying
implementation of {{{}collection_min{}}}, {{{}collection_max{}}},
{{collection_sum}} and {{{}collection_avg{}}}. That way we avoid code
duplication and make sure that the functions are consistent. However, that
consistency means that we inherit the design decisions taken for those
functions. The more remarkable ones IMO are
* {{sum}} and {{collection_sum}} return a value of the same type as the added
values, so any numeric value but {{decimal}} and {{varint}} can overflow.
> Add aggregation scalar functions on collections
> ---
>
> Key: CASSANDRA-18060
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18060
> Project: Cassandra
> Issue Type: New Feature
> Components: CQL/Semantics
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The new mechanism for dynamically building native functions introduced by
> CASSANDRA-17811 can be used to provide within-collection aggregation
> functions. We can use that mechanism to add new CQL functions to get:
> * The number of items in a collection.
> * The max/min items of a collection.
> * The sum/avg of the items of a numeric collection.
> * The keys or the values of a map.
> For example:
> {code:java}
> CREATE TABLE k.t (k int PRIMARY KEY, l list, m map);
> INSERT INTO t(k, l, m) VALUES (0, [1, 2, 3], {1:10, 2:20, 3:30});
> > SELECT map_keys(m), map_values(m) FROM t;
> system.map_keys(m) | system.map_values(m)
> +--
> {1, 2, 3} | [10, 20, 30]
> > SELECT collection_count(m), collection_count(l) FROM t;
> system.collection_count(m) | system.collection_count(l)
> +
> 3 | 3
> > SELECT collection_min(l), collection_max(l) FROM t;
> system.collection_min(l) | system.collection_max(l)
> --+--
> 1 |3
> > SELECT collection_sum(l), collection_avg(l) FROM t;
> system.collection_sum(l) | system.collection_avg(l)
> --+--
> 6 |2
> {code}
> Note that this type of aggregation is different from the kind of aggreg
[jira] [Comment Edited] (CASSANDRA-18060) Add aggregation scalar functions on collections
[
https://issues.apache.org/jira/browse/CASSANDRA-18060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17636066#comment-17636066
]
Andres de la Peña edited comment on CASSANDRA-18060 at 11/18/22 11:08 PM:
--
Here is the patch, and CI is running:
||PR||CI||
|[trunk|https://github.com/apache/cassandra/pull/2024]|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/2508/workflows/92f054d7-9386-498f-9ba4-330181cd4782]
[j11|https://app.circleci.com/pipelines/github/adelapena/cassandra/2508/workflows/8a0838e8-ffbb-424d-a572-3770f9a41632]|
Differently to [the
prototype|https://github.com/apache/cassandra/compare/trunk...adelapena:cassandra:17811-trunk-collections?expand=1]
mentioned during CASSANDRA-17811, the proposed PR uses the existing
aggregation functions available at {{AggregateFcts}} as the underlying
implementation of {{{}collection_min{}}}, {{{}collection_max{}}},
{{collection_sum}} and {{{}collection_avg{}}}. That way we avoid code
duplication and make sure that the functions are consistent. However, that
consistency means that we inherit the design decisions taken for those
functions. The more remarkable ones IMO are
* {{sum}} and {{collection_sum}} return a value of the same type as the added
values, so any numeric value but {{decimal}} and {{varint}} can overflow.
* {{avg}} and {{collection_avg}} return a value of the same type as the input
value, so for example the average of integers 1 and 2 is 1, instead of 1.5.
* {{avg}} and {{collection_avg}} return 0 for an empty list of values, instead
of the more correct {{{}NaN{}}}.
I guess that if we are unhappy with those behaviours we could have followup
tickets to try to improve them in both across-rows and across-collections-items
functions.
was (Author: adelapena):
Here is the patch, and CI is running:
||PR||CI||
|[trunk|https://github.com/apache/cassandra/pull/2024]|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/2508/workflows/92f054d7-9386-498f-9ba4-330181cd4782]
[j11|https://app.circleci.com/pipelines/github/adelapena/cassandra/2508/workflows/8a0838e8-ffbb-424d-a572-3770f9a41632]|
Differently to [the
prototype|https://github.com/apache/cassandra/compare/trunk...adelapena:cassandra:17811-trunk-collections?expand=1]
mentioned during CASSANDRA-17811, the proposed PR uses the existing
aggregation functions available at {{AggregateFcts}} as the underlying
implementation of {{{}collection_min{}}}, {{{}collection_max{}}},
{{collection_sum}} and {{{}collection_avg{}}}. That way we avoid code
duplication and make sure that the functions are consistent. However, that
consistency means that we inherit the design decisions taken for those
functions. The more remarkable ones IMO are
* {{sum}} and {{collection_sum}} return a value of the same type as the added
values, so any numeric value but {{decimal}} and {{varint}} can overflow.
* {{avg}} and {{collection_avg}} return a value of the same type as the input
value, so for example the average of integers 1 and 2 is 1, instead of 1.5.
* {{avg}} and {{collection_avg}} return 0 for an empty list of values, instead
of the more correct {{{}NaN{}}}.
I guess that we are unhappy with those behaviours we could have followup
tickets to try to improve them in both across-rows and across-collections-items
functions.
> Add aggregation scalar functions on collections
> ---
>
> Key: CASSANDRA-18060
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18060
> Project: Cassandra
> Issue Type: New Feature
> Components: CQL/Semantics
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The new mechanism for dynamically building native functions introduced by
> CASSANDRA-17811 can be used to provide within-collection aggregation
> functions. We can use that mechanism to add new CQL functions to get:
> * The number of items in a collection.
> * The max/min items of a collection.
> * The sum/avg of the items of a numeric collection.
> * The keys or the values of a map.
> For example:
> {code:java}
> CREATE TABLE k.t (k int PRIMARY KEY, l list, m map);
> INSERT INTO t(k, l, m) VALUES (0, [1, 2, 3], {1:10, 2:20, 3:30});
> > SELECT map_keys(m), map_values(m) FROM t;
> system.map_keys(m) | system.map_values(m)
> +--
> {1, 2, 3} | [10, 20, 30]
> > SELECT collection_count(m), collection_count(l) FROM t;
> system.collection_count(m) | system.collection_count(l)
> +
> 3 | 3
> > SELECT collection_min(l), collection_max(l) FROM t;
> system.collection_min(l) |
[jira] [Comment Edited] (CASSANDRA-18060) Add aggregation scalar functions on collections
[
https://issues.apache.org/jira/browse/CASSANDRA-18060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17636066#comment-17636066
]
Andres de la Peña edited comment on CASSANDRA-18060 at 11/18/22 11:10 PM:
--
Here is the patch, and CI is running:
||PR||CI||
|[trunk|https://github.com/apache/cassandra/pull/2024]|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/2508/workflows/92f054d7-9386-498f-9ba4-330181cd4782]
[j11|https://app.circleci.com/pipelines/github/adelapena/cassandra/2508/workflows/8a0838e8-ffbb-424d-a572-3770f9a41632]|
Differently to [the
prototype|https://github.com/apache/cassandra/compare/trunk...adelapena:cassandra:17811-trunk-collections?expand=1]
mentioned during CASSANDRA-17811, the proposed PR uses the existing
aggregation functions available at {{AggregateFcts}} as the underlying
implementation of {{{}collection_min{}}}, {{{}collection_max{}}},
{{collection_sum}} and {{{}collection_avg{}}}. That way we avoid code
duplication and make sure that the functions are consistent. However, that
consistency means that we inherit the design decisions taken for those
functions. The more remarkable ones IMO are
* {{sum}} and {{collection_sum}} return a value of the same type as the added
values, so any numeric value but {{decimal}} and {{varint}} can overflow.
* {{avg}} and {{collection_avg}} return a value of the same type as the input
value, so for example the average of integers 1 and 2 is 1, instead of 1.5.
* {{avg}} and {{collection_avg}} return 0 for an empty list of values, instead
of the more correct {{{}NaN{}}}.
I guess that if we are unhappy with those behaviours we could have followup
tickets to try to improve them in both across-rows and across-collection-items
functions.
was (Author: adelapena):
Here is the patch, and CI is running:
||PR||CI||
|[trunk|https://github.com/apache/cassandra/pull/2024]|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/2508/workflows/92f054d7-9386-498f-9ba4-330181cd4782]
[j11|https://app.circleci.com/pipelines/github/adelapena/cassandra/2508/workflows/8a0838e8-ffbb-424d-a572-3770f9a41632]|
Differently to [the
prototype|https://github.com/apache/cassandra/compare/trunk...adelapena:cassandra:17811-trunk-collections?expand=1]
mentioned during CASSANDRA-17811, the proposed PR uses the existing
aggregation functions available at {{AggregateFcts}} as the underlying
implementation of {{{}collection_min{}}}, {{{}collection_max{}}},
{{collection_sum}} and {{{}collection_avg{}}}. That way we avoid code
duplication and make sure that the functions are consistent. However, that
consistency means that we inherit the design decisions taken for those
functions. The more remarkable ones IMO are
* {{sum}} and {{collection_sum}} return a value of the same type as the added
values, so any numeric value but {{decimal}} and {{varint}} can overflow.
* {{avg}} and {{collection_avg}} return a value of the same type as the input
value, so for example the average of integers 1 and 2 is 1, instead of 1.5.
* {{avg}} and {{collection_avg}} return 0 for an empty list of values, instead
of the more correct {{{}NaN{}}}.
I guess that if we are unhappy with those behaviours we could have followup
tickets to try to improve them in both across-rows and across-collections-items
functions.
> Add aggregation scalar functions on collections
> ---
>
> Key: CASSANDRA-18060
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18060
> Project: Cassandra
> Issue Type: New Feature
> Components: CQL/Semantics
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The new mechanism for dynamically building native functions introduced by
> CASSANDRA-17811 can be used to provide within-collection aggregation
> functions. We can use that mechanism to add new CQL functions to get:
> * The number of items in a collection.
> * The max/min items of a collection.
> * The sum/avg of the items of a numeric collection.
> * The keys or the values of a map.
> For example:
> {code:java}
> CREATE TABLE k.t (k int PRIMARY KEY, l list, m map);
> INSERT INTO t(k, l, m) VALUES (0, [1, 2, 3], {1:10, 2:20, 3:30});
> > SELECT map_keys(m), map_values(m) FROM t;
> system.map_keys(m) | system.map_values(m)
> +--
> {1, 2, 3} | [10, 20, 30]
> > SELECT collection_count(m), collection_count(l) FROM t;
> system.collection_count(m) | system.collection_count(l)
> +
> 3 | 3
> > SELECT collection_min(l), collection_max(l) FROM t;
> system.collection_min(l)
[cassandra-website] branch asf-staging updated (d749d6088 -> 27a41b358)
This is an automated email from the ASF dual-hosted git repository. git-site-role pushed a change to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git discard d749d6088 generate docs for 9b5fa3b6 new 27a41b358 generate docs for 9b5fa3b6 This update added new revisions after undoing existing revisions. That is to say, some revisions that were in the old version of the branch are not in the new version. This situation occurs when a user --force pushes a change and generates a repository containing something like this: * -- * -- B -- O -- O -- O (d749d6088) \ N -- N -- N refs/heads/asf-staging (27a41b358) You should already have received notification emails for all of the O revisions, and so the following emails describe only the N revisions from the common base, B. Any revisions marked "omit" are not gone; other references still refer to them. Any revisions marked "discard" are gone forever. The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: content/doc/4.1/cassandra/architecture/dynamo.html | 44 ++- .../doc/4.1/cassandra/architecture/guarantees.html | 44 ++- content/doc/4.1/cassandra/architecture/index.html | 44 ++- .../doc/4.1/cassandra/architecture/messaging.html | 53 - .../doc/4.1/cassandra/architecture/overview.html | 44 ++- content/doc/4.1/cassandra/architecture/snitch.html | 44 ++- .../4.1/cassandra/architecture/storage_engine.html | 44 ++- .../doc/4.1/cassandra/architecture/streaming.html | 53 - .../configuration/cass_cl_archive_file.html| 44 ++- .../cassandra/configuration/cass_env_sh_file.html | 44 ++- .../configuration/cass_jvm_options_file.html | 44 ++- .../configuration/cass_logback_xml_file.html | 44 ++- .../cassandra/configuration/cass_rackdc_file.html | 44 ++- .../cassandra/configuration/cass_topo_file.html| 44 ++- .../cassandra/configuration/cass_yaml_file.html| 44 ++- .../4.1/cassandra/configuration/configuration.html | 51 +++- content/doc/4.1/cassandra/configuration/index.html | 44 ++- content/doc/4.1/cassandra/cql/SASI.html| 44 ++- content/doc/4.1/cassandra/cql/appendices.html | 44 ++- content/doc/4.1/cassandra/cql/changes.html | 44 ++- content/doc/4.1/cassandra/cql/cql_singlefile.html | 44 ++- content/doc/4.1/cassandra/cql/ddl.html | 44 ++- content/doc/4.1/cassandra/cql/definitions.html | 44 ++- content/doc/4.1/cassandra/cql/dml.html | 44 ++- content/doc/4.1/cassandra/cql/functions.html | 44 ++- content/doc/4.1/cassandra/cql/index.html | 44 ++- content/doc/4.1/cassandra/cql/indexes.html | 44 ++- content/doc/4.1/cassandra/cql/json.html| 44 ++- content/doc/4.1/cassandra/cql/mvs.html | 44 ++- content/doc/4.1/cassandra/cql/operators.html | 44 ++- content/doc/4.1/cassandra/cql/security.html| 44 ++- content/doc/4.1/cassandra/cql/triggers.html| 44 ++- content/doc/4.1/cassandra/cql/types.html | 44 ++- .../data_modeling/data_modeling_conceptual.html| 44 ++- .../data_modeling/data_modeling_logical.html | 44 ++- .../data_modeling/data_modeling_physical.html | 44 ++- .../data_modeling/data_modeling_queries.html | 44 ++- .../data_modeling/data_modeling_rdbms.html | 44 ++- .../data_modeling/data_modeling_refining.html | 44 ++- .../data_modeling/data_modeling_schema.html| 44 ++- .../data_modeling/data_modeling_tools.html | 44 ++- content/doc/4.1/cassandra/data_modeling/index.html | 44 ++- content/doc/4.1/cassandra/data_modeling/intro.html | 44 ++- content/doc/4.1/cassandra/faq/index.html | 44 ++- .../4.1/cassandra/getting_started/configuring.html | 44 ++- .../doc/4.1/cassandra/getting_started/drivers.html | 44 ++- .../doc/4.1/cassandra/getting_started/index.html | 44 ++- .../4.1/cassandra/getting_started/installing.html | 44 ++- .../doc/4.1/cassandra/getting_started/java11.html | 51 +++- .../4.1/cassandra/getting_started/production.html | 44 ++- .../4.1/cassandra/getting_started/querying.html| 44 ++- .../4.1/cassandra/getting_started/quickstart.html | 44 ++- content/doc/4.1/cassandra/new/index.html | 44 ++- content/doc/4.1/cassandra/new/virtualtables.html | 44 ++- .../doc/4.1/cassandra/operating/audit_logging.html | 46 ++- .../doc/4.1/cassandra/operating/auditlogging.html | 53 - content/doc/4.1/cassandra/operating/backups.html |
[jira] [Updated] (CASSANDRA-17854) Add JDK17 to our test docker images
[ https://issues.apache.org/jira/browse/CASSANDRA-17854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-17854: Fix Version/s: NA Source Control Link: https://github.com/apache/cassandra-builds/commit/cbdad2c546d4f6dc8ab9321a4c05be75311498c3 Resolution: Fixed Status: Resolved (was: Ready to Commit) > Add JDK17 to our test docker images > --- > > Key: CASSANDRA-17854 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17854 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: NA > > > In preparation to support JDK 17 I want to add JDK 17 to our test images to > enable our CIs for testing with JDK 17 > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17854) Add JDK17 to our test docker images
[ https://issues.apache.org/jira/browse/CASSANDRA-17854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17636078#comment-17636078 ] Ekaterina Dimitrova commented on CASSANDRA-17854: - [Patch|https://github.com/apache/cassandra-builds/commit/cbdad2c546d4f6dc8ab9321a4c05be75311498c3] committed to cassandra-builds. The two images are already pushed to docker hub. Thank you both! > Add JDK17 to our test docker images > --- > > Key: CASSANDRA-17854 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17854 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > > In preparation to support JDK 17 I want to add JDK 17 to our test images to > enable our CIs for testing with JDK 17 > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17854) Add JDK17 to our test docker images
[ https://issues.apache.org/jira/browse/CASSANDRA-17854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17636079#comment-17636079 ] Ekaterina Dimitrova commented on CASSANDRA-17854: - Almost forgot, for the record, I obtained approvals from [~mck] and [~brandon.williams] to push this through in Slack. > Add JDK17 to our test docker images > --- > > Key: CASSANDRA-17854 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17854 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: NA > > > In preparation to support JDK 17 I want to add JDK 17 to our test images to > enable our CIs for testing with JDK 17 > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17914) Argparse migration as the Python Optparse library is deprecated
[
https://issues.apache.org/jira/browse/CASSANDRA-17914?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brad Schoening updated CASSANDRA-17914:
---
Description:
[Deprecated since version 2.7: The optparse module is deprecated and will not
be developed further; development will continue with the argparse
module.|https://docs.python.org/2/library/optparse.html]
Argparse is described in [PEP 389 – argparse - New Command Line Parsing
Module|https://peps.python.org/pep-0389/]
A partial upgrade path from
[{{optparse}}|https://docs.python.org/3/library/optparse.html#module-optparse]
to
[{{argparse}}|https://docs.python.org/3/library/argparse.html#module-argparse]:
https://docs.python.org/3/library/argparse.html#upgrading-optparse-code
* Replace all
[{{optparse.OptionParser.add_option()}}|https://docs.python.org/3/library/optparse.html#optparse.OptionParser.add_option]
calls with
[{{ArgumentParser.add_argument()}}|https://docs.python.org/3/library/argparse.html#argparse.ArgumentParser.add_argument]
calls.
* Replace {{(options, args) = parser.parse_args()}} with {{args =
parser.parse_args()}} and add additional
[{{ArgumentParser.add_argument()}}|https://docs.python.org/3/library/argparse.html#argparse.ArgumentParser.add_argument]
calls for the positional arguments. Keep in mind that what was previously
called {{{}options{}}}, now in the
[{{argparse}}|https://docs.python.org/3/library/argparse.html#module-argparse]
context is called {{{}args{}}}.
* Replace
[{{optparse.OptionParser.disable_interspersed_args()}}|https://docs.python.org/3/library/optparse.html#optparse.OptionParser.disable_interspersed_args]
by using
[{{parse_intermixed_args()}}|https://docs.python.org/3/library/argparse.html#argparse.ArgumentParser.parse_intermixed_args]
instead of
[{{parse_args()}}|https://docs.python.org/3/library/argparse.html#argparse.ArgumentParser.parse_args].
* Replace callback actions and the {{callback_*}} keyword arguments with
{{type}} or {{action}} arguments.
* Replace string names for {{type}} keyword arguments with the corresponding
type objects (e.g. int, float, complex, etc).
* Replace {{optparse.Values}} with
[{{Namespace}}|https://docs.python.org/3/library/argparse.html#argparse.Namespace]
and {{optparse.OptionError}} and {{optparse.OptionValueError}} with
{{{}ArgumentError{}}}.
* Replace strings with implicit arguments such as {{%default}} or {{%prog}}
with the standard Python syntax to use dictionaries to format strings, that is,
{{%(default)s}} and {{{}%(prog)s{}}}.
* Replace the OptionParser constructor {{version}} argument with a call to
{{{}parser.add_argument('--version', action='version', version=''){}}}.
was:
[Deprecated since version 2.7: The optparse module is deprecated and will not
be developed further; development will continue with the argparse
module.|https://docs.python.org/2/library/optparse.html]
Argparse is described in [PEP 389 – argparse - New Command Line Parsing
Module|https://peps.python.org/pep-0389/]
> Argparse migration as the Python Optparse library is deprecated
> ---
>
> Key: CASSANDRA-17914
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17914
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Brad Schoening
>Priority: Normal
>
> [Deprecated since version 2.7: The optparse module is deprecated and will not
> be developed further; development will continue with the argparse
> module.|https://docs.python.org/2/library/optparse.html]
> Argparse is described in [PEP 389 – argparse - New Command Line Parsing
> Module|https://peps.python.org/pep-0389/]
>
> A partial upgrade path from
> [{{optparse}}|https://docs.python.org/3/library/optparse.html#module-optparse]
> to
> [{{argparse}}|https://docs.python.org/3/library/argparse.html#module-argparse]:
> https://docs.python.org/3/library/argparse.html#upgrading-optparse-code
> * Replace all
> [{{optparse.OptionParser.add_option()}}|https://docs.python.org/3/library/optparse.html#optparse.OptionParser.add_option]
> calls with
> [{{ArgumentParser.add_argument()}}|https://docs.python.org/3/library/argparse.html#argparse.ArgumentParser.add_argument]
> calls.
> * Replace {{(options, args) = parser.parse_args()}} with {{args =
> parser.parse_args()}} and add additional
> [{{ArgumentParser.add_argument()}}|https://docs.python.org/3/library/argparse.html#argparse.ArgumentParser.add_argument]
> calls for the positional arguments. Keep in mind that what was previously
> called {{{}options{}}}, now in the
> [{{argparse}}|https://docs.python.org/3/library/argparse.html#module-argparse]
> context is called {{{}args{}}}.
> * Replace
> [{{optparse.OptionParser.disable_interspersed_args()}}|https://docs.python.org/3/library/o
[cassandra-website] branch asf-staging updated (27a41b358 -> 12d3332c2)
This is an automated email from the ASF dual-hosted git repository. git-site-role pushed a change to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git discard 27a41b358 generate docs for 9b5fa3b6 new 12d3332c2 generate docs for 9b5fa3b6 This update added new revisions after undoing existing revisions. That is to say, some revisions that were in the old version of the branch are not in the new version. This situation occurs when a user --force pushes a change and generates a repository containing something like this: * -- * -- B -- O -- O -- O (27a41b358) \ N -- N -- N refs/heads/asf-staging (12d3332c2) You should already have received notification emails for all of the O revisions, and so the following emails describe only the N revisions from the common base, B. Any revisions marked "omit" are not gone; other references still refer to them. Any revisions marked "discard" are gone forever. The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: content/search-index.js | 2 +- site-ui/build/ui-bundle.zip | Bin 4970139 -> 4970139 bytes 2 files changed, 1 insertion(+), 1 deletion(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch asf-staging updated (12d3332c2 -> 3e5bcb0e2)
This is an automated email from the ASF dual-hosted git repository. git-site-role pushed a change to branch asf-staging in repository https://gitbox.apache.org/repos/asf/cassandra-website.git discard 12d3332c2 generate docs for 9b5fa3b6 new 3e5bcb0e2 generate docs for 9b5fa3b6 This update added new revisions after undoing existing revisions. That is to say, some revisions that were in the old version of the branch are not in the new version. This situation occurs when a user --force pushes a change and generates a repository containing something like this: * -- * -- B -- O -- O -- O (12d3332c2) \ N -- N -- N refs/heads/asf-staging (3e5bcb0e2) You should already have received notification emails for all of the O revisions, and so the following emails describe only the N revisions from the common base, B. Any revisions marked "omit" are not gone; other references still refer to them. Any revisions marked "discard" are gone forever. The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: site-ui/build/ui-bundle.zip | Bin 4970139 -> 4970139 bytes 1 file changed, 0 insertions(+), 0 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
