[jira] [Updated] (CASSANDRA-9312) Provide a way to retrieve the write time of a CQL row
[ https://issues.apache.org/jira/browse/CASSANDRA-9312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Lerer updated CASSANDRA-9312: -- Description: There is currently no way to retrieve the "writetime" of a CQL row. This is an issue for tables in which all dimensions are part of the primary key. Since Cassandra already stores a cell for the CQL row, it would make sense to provide a way to read its timestamp. This feature would be consistent with the concept of a row as an entity containing a number of optional columns, but able to exist on its own. +Additional information for newcomers+ As [~slebresne] suggested in the comments, this functionality can be done by allowing be achieved was: There is currently no way to retrieve the "writetime" of a CQL row. This is an issue for tables in which all dimensions are part of the primary key. Since Cassandra already stores a cell for the CQL row, it would make sense to provide a way to read its timestamp. This feature would be consistent with the concept of a row as an entity containing a number of optional columns, but able to exist on its own. > Provide a way to retrieve the write time of a CQL row > - > > Key: CASSANDRA-9312 > URL: https://issues.apache.org/jira/browse/CASSANDRA-9312 > Project: Cassandra > Issue Type: New Feature > Components: Legacy/CQL >Reporter: Nicolas Favre-Felix >Priority: Normal > Fix For: 4.x > > > There is currently no way to retrieve the "writetime" of a CQL row. This is > an issue for tables in which all dimensions are part of the primary key. > Since Cassandra already stores a cell for the CQL row, it would make sense to > provide a way to read its timestamp. This feature would be consistent with > the concept of a row as an entity containing a number of optional columns, > but able to exist on its own. > +Additional information for newcomers+ > As [~slebresne] suggested in the comments, this functionality can be done by > allowing be achieved -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17190) Add support for String contatenation through the "+" operator
[
https://issues.apache.org/jira/browse/CASSANDRA-17190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17458026#comment-17458026
]
Benjamin Lerer commented on CASSANDRA-17190:
{quote}
So to understand correctly, this would enable users to write queries like:
'Select col1 + col2 from'
{quote}
Yes or {{SELECT col1 + '-' + col2 FROM ...}}
The method signature looks good. You can probably even make it a full method
rather than an abstract one.
> Add support for String contatenation through the "+" operator
> -
>
> Key: CASSANDRA-17190
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17190
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Benjamin Lerer
>Assignee: Manish Ghildiyal
>Priority: Normal
> Labels: AdventCalendar2021, lhf
> Fix For: 4.x
>
>
> Since 4.0, Cassandra support operations on numeric types and on some temporal
> types.
> We should add support for string concatenations through the {{+}} operator.
> +Additional information for newcomers:+
> Cassandra has 2 string types: {{Text}} ({{UTF8Type}}) and ascii
> ({{AsciiType}}) both are sub-classes of ({{StringType}}). In order to add
> support for string concatenation you will need to add a new method to
> {{StringType}} and modify {{OperationFcts}} to add the new functions (one for
> each combination of types: ascii/ascii, ascii/text, text/ascii and text/text).
> The unit test should be added to {{OperationFctsTest}}.
> To allow for concatenating constants (eg: SELECT v1 + ' ' + v2 FROM ...) you
> will need to add a {{getPreferedTypeFor}} method to
> {{org.apache.cassandra.Constants.Type.STRING}} that determine the constant
> type based on its content (ascii or not).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17186) Guardrail for number of partition keys on IN queries
[
https://issues.apache.org/jira/browse/CASSANDRA-17186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-17186:
---
Change Category: Operability
Complexity: Low Hanging Fruit
Fix Version/s: 4.1
Status: Open (was: Triage Needed)
> Guardrail for number of partition keys on IN queries
>
>
> Key: CASSANDRA-17186
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17186
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Priority: Normal
> Labels: AdventCalendar2021, lhf
> Fix For: 4.1
>
>
> Add a guardrail for limiting the number of partitions restricted with an
> {{IN}} clause in a {{SELECT}} query, for example:
> {code:java}
> # Guardrail to warn or abort when querying with an IN restriction selecting
> # more partition keys than threshold.
> # The two thresholds default to -1 to disable.
> partition_keys_in_select:
> warn_threshold: -1
> abort_threshold: -1
> {code}
> +Additional information for newcomers:+
> * Add the configuration for the new guardrail on the number of partitions on
> IN queries in the guardrails section of cassandra.yaml.
> * Add a getPartitionKeysInSelect method in GuardrailsConfig returning a
> Threshold.Config object
> * Implement that method in GuardrailsOptions, which is the default
> yaml-based implementation of GuardrailsConfig
> * Add a Threshold guardrail named partitionKeysInSelect in Guardrails, using
> the previously created config
> * Define JMX-friendly getters and setters for the previously created config
> in GuardrailsMBean
> * Implement the JMX-friendly getters and setters in Guardrails
> * Now that we have the guardrail ready, it’s time to use it. We should
> search for a place to invoke the Guardrails.partitionKeysInSelect#guard
> method with the number of keys specified in select query. The
> SelectStatement#getSliceCommands methods look like good candidates for this.
> * Finally, add some tests for the new guardrail. Given that the new
> guardrail is a Threshold, our new test should probably extend ThresholdTester.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17186) Guardrail for number of partition keys on IN queries
[
https://issues.apache.org/jira/browse/CASSANDRA-17186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-17186:
---
Labels: AdventCalendar2021 lhf (was: )
> Guardrail for number of partition keys on IN queries
>
>
> Key: CASSANDRA-17186
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17186
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Priority: Normal
> Labels: AdventCalendar2021, lhf
>
> Add a guardrail for limiting the number of partitions restricted with an
> {{IN}} clause in a {{SELECT}} query, for example:
> {code:java}
> # Guardrail to warn or abort when querying with an IN restriction selecting
> # more partition keys than threshold.
> # The two thresholds default to -1 to disable.
> partition_keys_in_select:
> warn_threshold: -1
> abort_threshold: -1
> {code}
> +Additional information for newcomers:+
> * Add the configuration for the new guardrail on the number of partitions on
> IN queries in the guardrails section of cassandra.yaml.
> * Add a getPartitionKeysInSelect method in GuardrailsConfig returning a
> Threshold.Config object
> * Implement that method in GuardrailsOptions, which is the default
> yaml-based implementation of GuardrailsConfig
> * Add a Threshold guardrail named partitionKeysInSelect in Guardrails, using
> the previously created config
> * Define JMX-friendly getters and setters for the previously created config
> in GuardrailsMBean
> * Implement the JMX-friendly getters and setters in Guardrails
> * Now that we have the guardrail ready, it’s time to use it. We should
> search for a place to invoke the Guardrails.partitionKeysInSelect#guard
> method with the number of keys specified in select query. The
> SelectStatement#getSliceCommands methods look like good candidates for this.
> * Finally, add some tests for the new guardrail. Given that the new
> guardrail is a Threshold, our new test should probably extend ThresholdTester.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17186) Guardrail for number of partition keys on IN queries
[
https://issues.apache.org/jira/browse/CASSANDRA-17186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-17186:
---
Mentor: Andres de la Peña
> Guardrail for number of partition keys on IN queries
>
>
> Key: CASSANDRA-17186
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17186
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Priority: Normal
> Labels: AdventCalendar2021, lhf
>
> Add a guardrail for limiting the number of partitions restricted with an
> {{IN}} clause in a {{SELECT}} query, for example:
> {code:java}
> # Guardrail to warn or abort when querying with an IN restriction selecting
> # more partition keys than threshold.
> # The two thresholds default to -1 to disable.
> partition_keys_in_select:
> warn_threshold: -1
> abort_threshold: -1
> {code}
> +Additional information for newcomers:+
> * Add the configuration for the new guardrail on the number of partitions on
> IN queries in the guardrails section of cassandra.yaml.
> * Add a getPartitionKeysInSelect method in GuardrailsConfig returning a
> Threshold.Config object
> * Implement that method in GuardrailsOptions, which is the default
> yaml-based implementation of GuardrailsConfig
> * Add a Threshold guardrail named partitionKeysInSelect in Guardrails, using
> the previously created config
> * Define JMX-friendly getters and setters for the previously created config
> in GuardrailsMBean
> * Implement the JMX-friendly getters and setters in Guardrails
> * Now that we have the guardrail ready, it’s time to use it. We should
> search for a place to invoke the Guardrails.partitionKeysInSelect#guard
> method with the number of keys specified in select query. The
> SelectStatement#getSliceCommands methods look like good candidates for this.
> * Finally, add some tests for the new guardrail. Given that the new
> guardrail is a Threshold, our new test should probably extend ThresholdTester.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17186) Guardrail for number of partition keys on IN queries
[
https://issues.apache.org/jira/browse/CASSANDRA-17186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-17186:
---
Description:
Add a guardrail for limiting the number of partitions restricted with an {{IN}}
clause in a {{SELECT}} query, for example:
{code:java}
# Guardrail to warn or abort when querying with an IN restriction selecting
# more partition keys than threshold.
# The two thresholds default to -1 to disable.
partition_keys_in_select:
warn_threshold: -1
abort_threshold: -1
{code}
+Additional information for newcomers:+
* Add the configuration for the new guardrail on the number of partitions on
IN queries in the guardrails section of cassandra.yaml.
* Add a getPartitionKeysInSelect method in GuardrailsConfig returning a
Threshold.Config object
* Implement that method in GuardrailsOptions, which is the default yaml-based
implementation of GuardrailsConfig
* Add a Threshold guardrail named partitionKeysInSelect in Guardrails, using
the previously created config
* Define JMX-friendly getters and setters for the previously created config in
GuardrailsMBean
* Implement the JMX-friendly getters and setters in Guardrails
* Now that we have the guardrail ready, it’s time to use it. We should search
for a place to invoke the Guardrails.partitionKeysInSelect#guard method with
the number of keys specified in select query. The
SelectStatement#getSliceCommands methods look like good candidates for this.
* Finally, add some tests for the new guardrail. Given that the new guardrail
is a Threshold, our new test should probably extend ThresholdTester.
was:
Add a guardrail for limiting the number of partitions restricted with an {{IN}}
clause in a {{SELECT}} query, for example:
{code:java}
# Guardrail to warn or abort when querying with an IN restriction selecting
# more partition keys than threshold.
# The two thresholds default to -1 to disable.
partition_keys_in_select:
warn_threshold: -1
abort_threshold: -1
{code}
> Guardrail for number of partition keys on IN queries
>
>
> Key: CASSANDRA-17186
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17186
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Priority: Normal
>
> Add a guardrail for limiting the number of partitions restricted with an
> {{IN}} clause in a {{SELECT}} query, for example:
> {code:java}
> # Guardrail to warn or abort when querying with an IN restriction selecting
> # more partition keys than threshold.
> # The two thresholds default to -1 to disable.
> partition_keys_in_select:
> warn_threshold: -1
> abort_threshold: -1
> {code}
> +Additional information for newcomers:+
> * Add the configuration for the new guardrail on the number of partitions on
> IN queries in the guardrails section of cassandra.yaml.
> * Add a getPartitionKeysInSelect method in GuardrailsConfig returning a
> Threshold.Config object
> * Implement that method in GuardrailsOptions, which is the default
> yaml-based implementation of GuardrailsConfig
> * Add a Threshold guardrail named partitionKeysInSelect in Guardrails, using
> the previously created config
> * Define JMX-friendly getters and setters for the previously created config
> in GuardrailsMBean
> * Implement the JMX-friendly getters and setters in Guardrails
> * Now that we have the guardrail ready, it’s time to use it. We should
> search for a place to invoke the Guardrails.partitionKeysInSelect#guard
> method with the number of keys specified in select query. The
> SelectStatement#getSliceCommands methods look like good candidates for this.
> * Finally, add some tests for the new guardrail. Given that the new
> guardrail is a Threshold, our new test should probably extend ThresholdTester.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17199) Provide summary of failed SessionInfo's in StreamResultFuture
[
https://issues.apache.org/jira/browse/CASSANDRA-17199?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-17199:
---
Labels: AdventCalendar2021 lhf (was: AdventCalendar2021 lh)
> Provide summary of failed SessionInfo's in StreamResultFuture
> -
>
> Key: CASSANDRA-17199
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17199
> Project: Cassandra
> Issue Type: Improvement
> Components: Observability/Logging
>Reporter: Brendan Cicchi
>Priority: Normal
> Labels: AdventCalendar2021, lhf
> Fix For: 4.0.x
>
>
> Currently, we warn about the presence of one or more failed sessions existing
> in the final state and then an operator/user traces back through the logs to
> find any failed streams for troubleshooting.
> {code:java}
> private synchronized void maybeComplete()
> {
> if (finishedAllSessions())
> {
> StreamState finalState = getCurrentState();
> if (finalState.hasFailedSession())
> {
> logger.warn("[Stream #{}] Stream failed", planId);
> tryFailure(new StreamException(finalState, "Stream failed"));
> }
> else
> {
> logger.info("[Stream #{}] All sessions completed", planId);
> trySuccess(finalState);
> }
> }
> } {code}
> It would be helpful to log out a summary of the SessionInfo for each failed
> session since that should be accessible via the StreamState.
>
> This can be especially helpful for longer streaming operations like bootstrap
> where the failure could have been a long time back and all recent streams
> leading up to the warning actually are successful.
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17199) Provide summary of failed SessionInfo's in StreamResultFuture
[
https://issues.apache.org/jira/browse/CASSANDRA-17199?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-17199:
---
Labels: AdventCalendar2021 lh (was: )
> Provide summary of failed SessionInfo's in StreamResultFuture
> -
>
> Key: CASSANDRA-17199
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17199
> Project: Cassandra
> Issue Type: Improvement
> Components: Observability/Logging
>Reporter: Brendan Cicchi
>Priority: Normal
> Labels: AdventCalendar2021, lh
> Fix For: 4.0.x
>
>
> Currently, we warn about the presence of one or more failed sessions existing
> in the final state and then an operator/user traces back through the logs to
> find any failed streams for troubleshooting.
> {code:java}
> private synchronized void maybeComplete()
> {
> if (finishedAllSessions())
> {
> StreamState finalState = getCurrentState();
> if (finalState.hasFailedSession())
> {
> logger.warn("[Stream #{}] Stream failed", planId);
> tryFailure(new StreamException(finalState, "Stream failed"));
> }
> else
> {
> logger.info("[Stream #{}] All sessions completed", planId);
> trySuccess(finalState);
> }
> }
> } {code}
> It would be helpful to log out a summary of the SessionInfo for each failed
> session since that should be accessible via the StreamState.
>
> This can be especially helpful for longer streaming operations like bootstrap
> where the failure could have been a long time back and all recent streams
> leading up to the warning actually are successful.
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15297) nodetool can not create snapshot with snapshot name that have special character
[ https://issues.apache.org/jira/browse/CASSANDRA-15297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17457614#comment-17457614 ] Benjamin Lerer commented on CASSANDRA-15297: [~saranya_k] Yes. It just need some nodetool unit test. > nodetool can not create snapshot with snapshot name that have special > character > --- > > Key: CASSANDRA-15297 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15297 > Project: Cassandra > Issue Type: Bug > Components: Tool/nodetool >Reporter: maxwellguo >Assignee: maxwellguo >Priority: Normal > Labels: pull-request-available > Fix For: 4.x > > Attachments: after-fix.jpg, image.png, listsnapshots-p-s.jpg, > snapshot-listsnapshot-.jpg, snapshot-p-s.jpg > > Time Spent: 0.5h > Remaining Estimate: 0h > > we make snapshot through "nodetool snapshot -t snapshotname " , when > snapshotname contains special characters like "/", the make snapshot process > successfully , but the result > can be different ,when we check the data file directory or use "nodetool > listsnapshots". > here is some case : > 1. nodetool snapshot -t "p/s" > the listsnapshot resturns snapshot p for all table but actually the snapshot > name is "p/s"; > also the data directory is like the format : > datapath/snapshots/p/s/snapshot-datafile-link > !snapshot-p-s.jpg! > !listsnapshots-p-s.jpg! > 2. nodetool snapshot -t "/" > the listsnapshot resturns "there is not snapshot"; but the make snapshot > process return successfully and the data directory is like the format : > datapath/snapshots/snapshot-datafile-link > !snapshot-listsnapshot-.jpg! > the Attachements are the result under our environment. > so for me , we suggest that the snapshot name should not contains special > character. just throw exception and told the user not to use special > character. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17181) SchemaCQLHelperTest methods can be simplified
[
https://issues.apache.org/jira/browse/CASSANDRA-17181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17457314#comment-17457314
]
Benjamin Lerer commented on CASSANDRA-17181:
The patch looks good to me. I triggered a CI run
[here|https://app.circleci.com/pipelines/github/blerer/cassandra/249/workflows/b7573c32-defb-4a98-a051-025971e548a0].
[~e.dimitrova] would you have time for the second review?
> SchemaCQLHelperTest methods can be simplified
> -
>
> Key: CASSANDRA-17181
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17181
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Snapshots
>Reporter: Benjamin Lerer
>Assignee: Bartlomiej
>Priority: Normal
> Labels: AdventCalendar2021, lhf
> Fix For: 4.1
>
> Attachments: CASSANDRA-17181-4.0.patch
>
>
> {{SchemaCQLHelperTest}} is used during a snapshot to generate the
> {{schema.cql}} file. The methods accept the following paramaters:
> {{includeDroppedColumns}}, {{internals}} and {{ifNotExists}}.
> Those parameters are in practice always set to true by the calling code and
> therefore can be removed.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17181) SchemaCQLHelperTest methods can be simplified
[
https://issues.apache.org/jira/browse/CASSANDRA-17181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-17181:
---
Status: Review In Progress (was: Patch Available)
> SchemaCQLHelperTest methods can be simplified
> -
>
> Key: CASSANDRA-17181
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17181
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Snapshots
>Reporter: Benjamin Lerer
>Assignee: Bartlomiej
>Priority: Normal
> Labels: AdventCalendar2021, lhf
> Fix For: 4.1
>
> Attachments: CASSANDRA-17181-4.0.patch
>
>
> {{SchemaCQLHelperTest}} is used during a snapshot to generate the
> {{schema.cql}} file. The methods accept the following paramaters:
> {{includeDroppedColumns}}, {{internals}} and {{ifNotExists}}.
> Those parameters are in practice always set to true by the calling code and
> therefore can be removed.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17181) SchemaCQLHelperTest methods can be simplified
[
https://issues.apache.org/jira/browse/CASSANDRA-17181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-17181:
---
Test and Documentation Plan: The patch update existing tests
Status: Patch Available (was: Open)
> SchemaCQLHelperTest methods can be simplified
> -
>
> Key: CASSANDRA-17181
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17181
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Snapshots
>Reporter: Benjamin Lerer
>Assignee: Bartlomiej
>Priority: Normal
> Labels: AdventCalendar2021, lhf
> Fix For: 4.1
>
> Attachments: CASSANDRA-17181-4.0.patch
>
>
> {{SchemaCQLHelperTest}} is used during a snapshot to generate the
> {{schema.cql}} file. The methods accept the following paramaters:
> {{includeDroppedColumns}}, {{internals}} and {{ifNotExists}}.
> Those parameters are in practice always set to true by the calling code and
> therefore can be removed.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17199) Provide summary of failed SessionInfo's in StreamResultFuture
[
https://issues.apache.org/jira/browse/CASSANDRA-17199?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-17199:
---
Mentor: Brandon Williams
> Provide summary of failed SessionInfo's in StreamResultFuture
> -
>
> Key: CASSANDRA-17199
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17199
> Project: Cassandra
> Issue Type: Improvement
> Components: Observability/Logging
>Reporter: Brendan Cicchi
>Priority: Normal
> Fix For: 4.0.x
>
>
> Currently, we warn about the presence of one or more failed sessions existing
> in the final state and then an operator/user traces back through the logs to
> find any failed streams for troubleshooting.
> {code:java}
> private synchronized void maybeComplete()
> {
> if (finishedAllSessions())
> {
> StreamState finalState = getCurrentState();
> if (finalState.hasFailedSession())
> {
> logger.warn("[Stream #{}] Stream failed", planId);
> tryFailure(new StreamException(finalState, "Stream failed"));
> }
> else
> {
> logger.info("[Stream #{}] All sessions completed", planId);
> trySuccess(finalState);
> }
> }
> } {code}
> It would be helpful to log out a summary of the SessionInfo for each failed
> session since that should be accessible via the StreamState.
>
> This can be especially helpful for longer streaming operations like bootstrap
> where the failure could have been a long time back and all recent streams
> leading up to the warning actually are successful.
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17133) Broken test_timeuuid - upgrade_tests.cql_tests
[
https://issues.apache.org/jira/browse/CASSANDRA-17133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17457138#comment-17457138
]
Benjamin Lerer edited comment on CASSANDRA-17133 at 12/10/21, 1:08 PM:
---
I had a look at the code and it seems that the mistake is mine. We did not need
to add those new functions in CASSANDRA-17029 as the functionality was already
there.
We had the following functions:
* toDate(timestamp)
* toTimestamp(date)
* mintimeuuid(timestamp)
* maxtimeuuid(timestamp)
Those functions were not overloaded so they will be the ones being picked up
but the code allow deserialization from integer to the timestampt type or the
date type.
by consequence adding new function was not needed and in fact lead to a
slightly different behavior. What I would suggest it to remove the methods
added by CASSANDRA-17029 and modify the tests to verify the behavior with int
an long inputs.
Sorry for not realizing that sooner. :-(
was (Author: blerer):
I had a look at the code and it seems that the mistake is mine. We did not need
to add those new functions in CASSANDRA-17029 as the functionality was already
there.
We had the following functions:
* toDate(timestamp)
* toTimestamp(date)
* mintimeuuid(timestamp)
* maxtimeuuid(timestamp)
Those functions were not overloaded so they will be the ones being picked up
but the code allow deserialization from integer to the timestampt type or the
date type.
by consequence adding new function was not needed and in fact lead to a
slightly different behavior. What I would suggest it to remove the methods
added by CASSANDRA-17029 and modify the tests to verify the behavior with int
an long inputs.
Sorry for not realizing that sooner. :-(
> Broken test_timeuuid - upgrade_tests.cql_tests
> --
>
> Key: CASSANDRA-17133
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17133
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Semantics
>Reporter: Yifan Cai
>Assignee: Kanthi Subramanian
>Priority: Normal
> Fix For: 4.x
>
>
> Both CircleCI and Jenkins build failed at test_timeuuid with the following
> error.
> {quote}cassandra.InvalidRequest: Error from server: code=2200 [Invalid query]
> message="Ambiguous call to function maxtimeuuid (can be matched by following
> signatures: system.maxtimeuuid : (bigint) -> timeuuid, system.maxtimeuuid :
> (timestamp) -> timeuuid): use type casts to disambiguate"{quote}
> https://app.circleci.com/pipelines/github/yifan-c/cassandra/273/workflows/7a855174-823a-4553-ad09-25623747a58e/jobs/1884/tests#failed-test-0
> https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/1272/tests/
> The change was added in CASSANDRA-17029.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17133) Broken test_timeuuid - upgrade_tests.cql_tests
[
https://issues.apache.org/jira/browse/CASSANDRA-17133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17457138#comment-17457138
]
Benjamin Lerer commented on CASSANDRA-17133:
I had a look at the code and it seems that the mistake is mine. We did not need
to add those new functions in CASSANDRA-17029 as the functionality was already
there.
We had the following functions:
* toDate(timestamp)
* toTimestamp(date)
* mintimeuuid(timestamp)
* maxtimeuuid(timestamp)
Those functions were not overloaded so they will be the ones being picked up
but the code allow deserialization from integer to the timestampt type or the
date type.
by consequence adding new function was not needed and in fact lead to a
slightly different behavior. What I would suggest it to remove the methods
added by CASSANDRA-17029 and modify the tests to verify the behavior with int
an long inputs.
Sorry for not realizing that sooner. :-(
> Broken test_timeuuid - upgrade_tests.cql_tests
> --
>
> Key: CASSANDRA-17133
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17133
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Semantics
>Reporter: Yifan Cai
>Assignee: Kanthi Subramanian
>Priority: Normal
> Fix For: 4.x
>
>
> Both CircleCI and Jenkins build failed at test_timeuuid with the following
> error.
> {quote}cassandra.InvalidRequest: Error from server: code=2200 [Invalid query]
> message="Ambiguous call to function maxtimeuuid (can be matched by following
> signatures: system.maxtimeuuid : (bigint) -> timeuuid, system.maxtimeuuid :
> (timestamp) -> timeuuid): use type casts to disambiguate"{quote}
> https://app.circleci.com/pipelines/github/yifan-c/cassandra/273/workflows/7a855174-823a-4553-ad09-25623747a58e/jobs/1884/tests#failed-test-0
> https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/1272/tests/
> The change was added in CASSANDRA-17029.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17181) SchemaCQLHelperTest methods can be simplified
[
https://issues.apache.org/jira/browse/CASSANDRA-17181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17456559#comment-17456559
]
Benjamin Lerer commented on CASSANDRA-17181:
Thanks a lot [~bkowalczyyk]. I will review your patch tomorrow :-)
> SchemaCQLHelperTest methods can be simplified
> -
>
> Key: CASSANDRA-17181
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17181
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Snapshots
>Reporter: Benjamin Lerer
>Assignee: Bartlomiej
>Priority: Normal
> Labels: AdventCalendar2021, lhf
> Fix For: 4.1
>
> Attachments: CASSANDRA-17181-4.0.patch
>
>
> {{SchemaCQLHelperTest}} is used during a snapshot to generate the
> {{schema.cql}} file. The methods accept the following paramaters:
> {{includeDroppedColumns}}, {{internals}} and {{ifNotExists}}.
> Those parameters are in practice always set to true by the calling code and
> therefore can be removed.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17181) SchemaCQLHelperTest methods can be simplified
[
https://issues.apache.org/jira/browse/CASSANDRA-17181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-17181:
---
Workflow: Copy of Cassandra Default Workflow (was: Copy of Cassandra Bug
Workflow)
Issue Type: Improvement (was: Bug)
> SchemaCQLHelperTest methods can be simplified
> -
>
> Key: CASSANDRA-17181
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17181
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Snapshots
>Reporter: Benjamin Lerer
>Assignee: Bartlomiej
>Priority: Normal
> Labels: AdventCalendar2021, lhf
> Fix For: 4.1
>
> Attachments: CASSANDRA-17181-4.0.patch
>
>
> {{SchemaCQLHelperTest}} is used during a snapshot to generate the
> {{schema.cql}} file. The methods accept the following paramaters:
> {{includeDroppedColumns}}, {{internals}} and {{ifNotExists}}.
> Those parameters are in practice always set to true by the calling code and
> therefore can be removed.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16664) Log JVM Arguments at in-JVM Test Class Initialization
[
https://issues.apache.org/jira/browse/CASSANDRA-16664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-16664:
---
Mentor: Paulo Motta
> Log JVM Arguments at in-JVM Test Class Initialization
> -
>
> Key: CASSANDRA-16664
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16664
> Project: Cassandra
> Issue Type: Improvement
> Components: Test/dtest/java
>Reporter: Caleb Rackliffe
>Priority: Normal
> Labels: AdventCalendar2021, lhf
> Fix For: 4.0.x, 4.x
>
>
> Normal C* startup flows through {{CassandraDaemon.setup()}}, which calls
> {{logSystemInfo()}}, logging JVM arguments and a number of other useful bits
> of information. The in-JVM dtest startup does not flow through
> {{CassandraDaemon.setup()}}, and therefore does not. It would be useful for
> troubleshooting purposes if {{TestBaseImpl}} logged the JVM arguments before
> moving into executing tests.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16664) Log JVM Arguments at in-JVM Test Class Initialization
[
https://issues.apache.org/jira/browse/CASSANDRA-16664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-16664:
---
Labels: AdventCalendar2021 lhf (was: )
> Log JVM Arguments at in-JVM Test Class Initialization
> -
>
> Key: CASSANDRA-16664
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16664
> Project: Cassandra
> Issue Type: Improvement
> Components: Test/dtest/java
>Reporter: Caleb Rackliffe
>Priority: Normal
> Labels: AdventCalendar2021, lhf
> Fix For: 4.0.x, 4.x
>
>
> Normal C* startup flows through {{CassandraDaemon.setup()}}, which calls
> {{logSystemInfo()}}, logging JVM arguments and a number of other useful bits
> of information. The in-JVM dtest startup does not flow through
> {{CassandraDaemon.setup()}}, and therefore does not. It would be useful for
> troubleshooting purposes if {{TestBaseImpl}} logged the JVM arguments before
> moving into executing tests.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17198) Allow to filter using LIKE predicates
[
https://issues.apache.org/jira/browse/CASSANDRA-17198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-17198:
---
Change Category: Semantic
Complexity: Low Hanging Fruit
Fix Version/s: 4.x
Mentor: Benjamin Lerer
> Allow to filter using LIKE predicates
> -
>
> Key: CASSANDRA-17198
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17198
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Syntax
>Reporter: Benjamin Lerer
>Priority: Normal
> Labels: AdventCalendar2021, lhf
> Fix For: 4.x
>
>
> {{LIKE}} predicates can only be used with the SASI indices. In several
> usecases (e.g. querying the {{settings}} virtual table) it makes sense to
> support them for filtering.
> + Additional information for newcomers:+
> There are some checks in the {{StatementRestrictions}} constructor and on
> {{LikeRestriction}} that need to be removed for allowing filtering using LIKE
> on clustering and regular columns.
> For filtering on partition columns the {{needFiltering}} methods in
> {{PartitionKeySingleRestrictionSet}} will need to be modified to return true
> when LIKE predicate are used.
> The unit tests should go in {{SelectTest}}.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17198) Allow to filter using LIKE predicates
[
https://issues.apache.org/jira/browse/CASSANDRA-17198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-17198:
---
Labels: AdventCalendar2021 lhf (was: )
> Allow to filter using LIKE predicates
> -
>
> Key: CASSANDRA-17198
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17198
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Syntax
>Reporter: Benjamin Lerer
>Priority: Normal
> Labels: AdventCalendar2021, lhf
>
> {{LIKE}} predicates can only be used with the SASI indices. In several
> usecases (e.g. querying the {{settings}} virtual table) it makes sense to
> support them for filtering.
> + Additional information for newcomers:+
> There are some checks in the {{StatementRestrictions}} constructor and on
> {{LikeRestriction}} that need to be removed for allowing filtering using LIKE
> on clustering and regular columns.
> For filtering on partition columns the {{needFiltering}} methods in
> {{PartitionKeySingleRestrictionSet}} will need to be modified to return true
> when LIKE predicate are used.
> The unit tests should go in {{SelectTest}}.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17198) Allow to filter using LIKE predicates
Benjamin Lerer created CASSANDRA-17198:
--
Summary: Allow to filter using LIKE predicates
Key: CASSANDRA-17198
URL: https://issues.apache.org/jira/browse/CASSANDRA-17198
Project: Cassandra
Issue Type: Improvement
Components: CQL/Syntax
Reporter: Benjamin Lerer
{{LIKE}} predicates can only be used with the SASI indices. In several usecases
(e.g. querying the {{settings}} virtual table) it makes sense to support them
for filtering.
+ Additional information for newcomers:+
There are some checks in the {{StatementRestrictions}} constructor and on
{{LikeRestriction}} that need to be removed for allowing filtering using LIKE
on clustering and regular columns.
For filtering on partition columns the {{needFiltering}} methods in
{{PartitionKeySingleRestrictionSet}} will need to be modified to return true
when LIKE predicate are used.
The unit tests should go in {{SelectTest}}.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17189) Guardrail for page size
[
https://issues.apache.org/jira/browse/CASSANDRA-17189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-17189:
---
Labels: AdventCalendar2021 lhf (was: )
> Guardrail for page size
> ---
>
> Key: CASSANDRA-17189
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17189
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Priority: Normal
> Labels: AdventCalendar2021, lhf
> Fix For: 4.1
>
>
> Add guardrail limiting the query page size, for example:
> {code}
> # Guardrail to warn about or reject page sizes greater than threshold.
> # The two thresholds default to -1 to disable.
> page_size:
> warn_threshold: -1
> abort_threshold: -1
> {code}
> Initially this can be based on the specified number of rows used as page
> size, although it would be ideal to also limit the actual size in bytes of
> the returned pages.
> +Additional information for newcomers:+
> # Add the configuration for the new guardrail on page size in the guardrails
> section of cassandra.yaml.
> # Add a getPageSize method in GuardrailsConfig returning a Threshold.Config
> object
> # Implement that method in GuardrailsOptions, which is the default yaml-based
> implementation of GuardrailsConfig
> # Add a Threshold guardrail named pageSize in Guardrails, using the
> previously created config
> # Define JMX-friendly getters and setters for the previously created config
> in GuardrailsMBean
> # Implement the JMX-friendly getters and setters in Guardrails
> # Now that we have the guardrail ready, it’s time to use it. We should search
> for a place to invoke the Guardrails.pageSize#guard method with the page size
> that each query is going to use. The DataLimits#forPaging methods look like
> good candidates for this.
> # Finally, add some tests for the new guardrail. Given that the new guardrail
> is a Threshold, our new test should probably extend ThresholdTester.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17189) Guardrail for page size
[
https://issues.apache.org/jira/browse/CASSANDRA-17189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-17189:
---
Description:
Add guardrail limiting the query page size, for example:
{code}
# Guardrail to warn about or reject page sizes greater than threshold.
# The two thresholds default to -1 to disable.
page_size:
warn_threshold: -1
abort_threshold: -1
{code}
Initially this can be based on the specified number of rows used as page size,
although it would be ideal to also limit the actual size in bytes of the
returned pages.
+Additional information for newcomers:+
# Add the configuration for the new guardrail on page size in the guardrails
section of cassandra.yaml.
# Add a getPageSize method in GuardrailsConfig returning a Threshold.Config
object
# Implement that method in GuardrailsOptions, which is the default yaml-based
implementation of GuardrailsConfig
# Add a Threshold guardrail named pageSize in Guardrails, using the previously
created config
# Define JMX-friendly getters and setters for the previously created config in
GuardrailsMBean
# Implement the JMX-friendly getters and setters in Guardrails
# Now that we have the guardrail ready, it’s time to use it. We should search
for a place to invoke the Guardrails.pageSize#guard method with the page size
that each query is going to use. The DataLimits#forPaging methods look like
good candidates for this.
# Finally, add some tests for the new guardrail. Given that the new guardrail
is a Threshold, our new test should probably extend ThresholdTester.
was:
Add guardrail limiting the query page size, for example:
{code}
# Guardrail to warn about or reject page sizes greater than threshold.
# The two thresholds default to -1 to disable.
page_size:
warn_threshold: -1
abort_threshold: -1
{code}
Initially this can be based on the specified number of rows used as page size,
although it would be ideal to also limit the actual size in bytes of the
returned pages.
> Guardrail for page size
> ---
>
> Key: CASSANDRA-17189
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17189
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Priority: Normal
> Fix For: 4.1
>
>
> Add guardrail limiting the query page size, for example:
> {code}
> # Guardrail to warn about or reject page sizes greater than threshold.
> # The two thresholds default to -1 to disable.
> page_size:
> warn_threshold: -1
> abort_threshold: -1
> {code}
> Initially this can be based on the specified number of rows used as page
> size, although it would be ideal to also limit the actual size in bytes of
> the returned pages.
> +Additional information for newcomers:+
> # Add the configuration for the new guardrail on page size in the guardrails
> section of cassandra.yaml.
> # Add a getPageSize method in GuardrailsConfig returning a Threshold.Config
> object
> # Implement that method in GuardrailsOptions, which is the default yaml-based
> implementation of GuardrailsConfig
> # Add a Threshold guardrail named pageSize in Guardrails, using the
> previously created config
> # Define JMX-friendly getters and setters for the previously created config
> in GuardrailsMBean
> # Implement the JMX-friendly getters and setters in Guardrails
> # Now that we have the guardrail ready, it’s time to use it. We should search
> for a place to invoke the Guardrails.pageSize#guard method with the page size
> that each query is going to use. The DataLimits#forPaging methods look like
> good candidates for this.
> # Finally, add some tests for the new guardrail. Given that the new guardrail
> is a Threshold, our new test should probably extend ThresholdTester.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17189) Guardrail for page size
[
https://issues.apache.org/jira/browse/CASSANDRA-17189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-17189:
---
Change Category: Operability
Complexity: Low Hanging Fruit
Fix Version/s: 4.1
Mentor: Andres de la Peña
Status: Open (was: Triage Needed)
> Guardrail for page size
> ---
>
> Key: CASSANDRA-17189
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17189
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Priority: Normal
> Fix For: 4.1
>
>
> Add guardrail limiting the query page size, for example:
> {code}
> # Guardrail to warn about or reject page sizes greater than threshold.
> # The two thresholds default to -1 to disable.
> page_size:
> warn_threshold: -1
> abort_threshold: -1
> {code}
> Initially this can be based on the specified number of rows used as page
> size, although it would be ideal to also limit the actual size in bytes of
> the returned pages.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15510) BTree: Improve Building, Inserting and Transforming
[
https://issues.apache.org/jira/browse/CASSANDRA-15510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-15510:
---
Status: Review In Progress (was: Patch Available)
> BTree: Improve Building, Inserting and Transforming
> ---
>
> Key: CASSANDRA-15510
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15510
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Other
>Reporter: Benedict Elliott Smith
>Assignee: Benedict Elliott Smith
>Priority: Normal
> Fix For: 4.0.x, 4.x
>
>
> This work was originally undertaken as a follow-up to CASSANDRA-15367 to
> ensure performance is strictly improved, but it may no longer be needed for
> that purpose. It’s still hugely impactful, however. It remains to be
> decided where this should land.
> The current {{BTree}} implementation is suboptimal in a number of ways, with
> very little focus having been given to its performance besides its
> memory-occupancy. This patch aims to address that, specifically improving
> the performance and allocations involved in: building, transforming and
> inserting into a tree.
> To facilitate this work, the {{BTree}} definition is modified slightly, so
> that we can perform some simple arithmetic on tree sizes. Specifically,
> trees of depth n are defined to have a maximum capacity of {{branchFactor^n -
> 1}}, which translates into capping the number of leaf children at
> {{branchFactor-1}}, as opposed to {{branchFactor}}. Since {{branchFactor}}
> is a power of 2, this permits fast tree size arithmetic, enabling some of
> these changes.
> h2. Building
> The static build method has been modified to utilise dedicated
> {{buildPerfect}} methods that build either perfectly dense or perfectly
> sparse sub-trees. These perfect trees all share their {{sizeMap}} with each
> other, and can be built more efficiently than trees of arbitrary size. The
> specifics are described in detail in the comments, but this building block
> can be used to construct trees of any size, using at most one child at each
> level that is not either perfectly sparse or perfectly dense. Bulk methods
> are used where possible.
> For large trees this can produce up to 30x throughput improvement and 30%
> allocation reduction vs 3.0 (TBC, and to be tested vs 4.0).
> {{FastBuilder}} is introduced for building a tree in-order (or in reverse)
> without duplicate elements to resolve, without necessarily knowing the size
> upfront. This meets the needs of most use cases. Data is built directly
> into nodes, with up to one already-constructed node, and one partially
> constructed node, on each level, being mutated to share their contents in the
> event of insufficient data to populate the tree. These builders are
> thread-locally shared. These leads to minimal copying, the same sharing of
> {{sizeMap}} as above, zero wasted allocations, and results in minimal
> difference in performance between utilising the less-ergonomic static build
> and builder approach.
> For large trees this leads to ~4.5x throughput improvement, and 70% reduction
> in allocations vs a normal Builder. For small trees performance is
> comparable, but allocations similarly reduced.
> h2. Inserting
> It turns out that we only ever insert another tree into a tree, so we exploit
> this to implement an efficient union of two trees, operating on them directly
> via stacks in the transformer, instead of via a collection interface. A
> builder-like object is introduced that shares functionality with
> {{FastBuilder}}, and permits us to build the result of the union directly
> into the final nodes, reusing as much of the original trees as possible.
> Bulk methods are used where possible.
> The result is not _uniformly_ faster, but is _significantly_ faster on
> average: median _improvement_ of 1.4x (that is, 2.4x total throughput), mean
> improvement of 10x. Worst reduction is 30%, and it may be that we can
> isolate and alleviate that. Allocations are also reduced significantly, with
> a median of 30% and mean of 42% for the tested workloads. As the trees get
> larger the improvement drops, but remains uniformly lower.
> h2. Transforming
> Transformations garbage overhead is minimal, i.e. the main allocations are
> those necessary to represent the new tree. It is significantly faster and
> particularly more efficient when removing elements, utilising the shared
> functionality of the builder and transformer objects to define an efficient
> builder that reuses as much of the original tree as possible.
> We also introduce dedicated {{transform}} methods (that forbid returning
> {{null}}), and {{BiFunction}} transformations to permit efficient follow-ups.
--
This message was
[jira] [Commented] (CASSANDRA-17184) Add += and -= syntax to ALTER TABLE WITH
[
https://issues.apache.org/jira/browse/CASSANDRA-17184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17454034#comment-17454034
]
Benjamin Lerer commented on CASSANDRA-17184:
[~aleks_v] I assigned the ticket to you :-)
> Add += and -= syntax to ALTER TABLE WITH
>
>
> Key: CASSANDRA-17184
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17184
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Syntax
>Reporter: Benjamin Lerer
>Assignee: Aleksandr Volochnev
>Priority: Normal
> Labels: AdventCalendar2021, lhf
> Fix For: 4.x
>
>
> We have 2 types of table properties in CQL: simple ones (comment,
> gc_grace_seconds, ...), which are basically of type text (even if, we
> historically allow constants of any type) and complex ones (compaction,
> caching...), which are basically map.
> The only syntax that {{ALTER TABLE WITH}} supports is of setting a property,
> and so for the later kind, we basically always have to provide the new full
> map for the option. To take an example, say you have a table with compaction
> and want to enable compaction logging you will have to provide the all map.
> In order to avoid that problem we can add support for the {{+=}} (and {{-=}}
> ideally) syntax that already exists for maps otherwise, and support:
> {code}
> ALTER TABLE t WITH compaction+= { 'log_all' : 'true' }
> {code}
> +Additional info for newcomers:+
> In order to implement this change you will need to change the Parser.g ANTLR
> file located in the src/antlr directory and the java classes corresponding to
> the different alter statements located in the
> {{org.apache.cassandra.cql3.statements.schema}} package.
> The unit test for the CQL logic are located under
> {{org.apache.cassandra.cql3.validation}}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-17184) Add += and -= syntax to ALTER TABLE WITH
[
https://issues.apache.org/jira/browse/CASSANDRA-17184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer reassigned CASSANDRA-17184:
--
Assignee: Aleksandr Volochnev (was: Aleksandar Vidakovic)
> Add += and -= syntax to ALTER TABLE WITH
>
>
> Key: CASSANDRA-17184
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17184
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Syntax
>Reporter: Benjamin Lerer
>Assignee: Aleksandr Volochnev
>Priority: Normal
> Labels: AdventCalendar2021, lhf
> Fix For: 4.x
>
>
> We have 2 types of table properties in CQL: simple ones (comment,
> gc_grace_seconds, ...), which are basically of type text (even if, we
> historically allow constants of any type) and complex ones (compaction,
> caching...), which are basically map.
> The only syntax that {{ALTER TABLE WITH}} supports is of setting a property,
> and so for the later kind, we basically always have to provide the new full
> map for the option. To take an example, say you have a table with compaction
> and want to enable compaction logging you will have to provide the all map.
> In order to avoid that problem we can add support for the {{+=}} (and {{-=}}
> ideally) syntax that already exists for maps otherwise, and support:
> {code}
> ALTER TABLE t WITH compaction+= { 'log_all' : 'true' }
> {code}
> +Additional info for newcomers:+
> In order to implement this change you will need to change the Parser.g ANTLR
> file located in the src/antlr directory and the java classes corresponding to
> the different alter statements located in the
> {{org.apache.cassandra.cql3.statements.schema}} package.
> The unit test for the CQL logic are located under
> {{org.apache.cassandra.cql3.validation}}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-17184) Add += and -= syntax to ALTER TABLE WITH
[
https://issues.apache.org/jira/browse/CASSANDRA-17184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer reassigned CASSANDRA-17184:
--
Assignee: Aleksandar Vidakovic
> Add += and -= syntax to ALTER TABLE WITH
>
>
> Key: CASSANDRA-17184
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17184
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Syntax
>Reporter: Benjamin Lerer
>Assignee: Aleksandar Vidakovic
>Priority: Normal
> Labels: AdventCalendar2021, lhf
> Fix For: 4.x
>
>
> We have 2 types of table properties in CQL: simple ones (comment,
> gc_grace_seconds, ...), which are basically of type text (even if, we
> historically allow constants of any type) and complex ones (compaction,
> caching...), which are basically map.
> The only syntax that {{ALTER TABLE WITH}} supports is of setting a property,
> and so for the later kind, we basically always have to provide the new full
> map for the option. To take an example, say you have a table with compaction
> and want to enable compaction logging you will have to provide the all map.
> In order to avoid that problem we can add support for the {{+=}} (and {{-=}}
> ideally) syntax that already exists for maps otherwise, and support:
> {code}
> ALTER TABLE t WITH compaction+= { 'log_all' : 'true' }
> {code}
> +Additional info for newcomers:+
> In order to implement this change you will need to change the Parser.g ANTLR
> file located in the src/antlr directory and the java classes corresponding to
> the different alter statements located in the
> {{org.apache.cassandra.cql3.statements.schema}} package.
> The unit test for the CQL logic are located under
> {{org.apache.cassandra.cql3.validation}}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17190) Add support for String contatenation through the "+" operator
[
https://issues.apache.org/jira/browse/CASSANDRA-17190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-17190:
---
Labels: AdventCalendar2021 lhf (was: )
> Add support for String contatenation through the "+" operator
> -
>
> Key: CASSANDRA-17190
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17190
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Benjamin Lerer
>Priority: Normal
> Labels: AdventCalendar2021, lhf
> Fix For: 4.x
>
>
> Since 4.0, Cassandra support operations on numeric types and on some temporal
> types.
> We should add support for string concatenations through the {{+}} operator.
> +Additional information for newcomers:+
> Cassandra has 2 string types: {{Text}} ({{UTF8Type}}) and ascii
> ({{AsciiType}}) both are sub-classes of ({{StringType}}). In order to add
> support for string concatenation you will need to add a new method to
> {{StringType}} and modify {{OperationFcts}} to add the new functions (one for
> each combination of types: ascii/ascii, ascii/text, text/ascii and text/text).
> The unit test should be added to {{OperationFctsTest}}.
> To allow for concatenating constants (eg: SELECT v1 + ' ' + v2 FROM ...) you
> will need to add a {{getPreferedTypeFor}} method to
> {{org.apache.cassandra.Constants.Type.STRING}} that determine the constant
> type based on its content (ascii or not).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17190) Add support for String contatenation through the "+" operator
[
https://issues.apache.org/jira/browse/CASSANDRA-17190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-17190:
---
Change Category: Semantic
Complexity: Low Hanging Fruit
Fix Version/s: 4.x
Status: Open (was: Triage Needed)
> Add support for String contatenation through the "+" operator
> -
>
> Key: CASSANDRA-17190
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17190
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Benjamin Lerer
>Priority: Normal
> Fix For: 4.x
>
>
> Since 4.0, Cassandra support operations on numeric types and on some temporal
> types.
> We should add support for string concatenations through the {{+}} operator.
> +Additional information for newcomers:+
> Cassandra has 2 string types: {{Text}} ({{UTF8Type}}) and ascii
> ({{AsciiType}}) both are sub-classes of ({{StringType}}). In order to add
> support for string concatenation you will need to add a new method to
> {{StringType}} and modify {{OperationFcts}} to add the new functions (one for
> each combination of types: ascii/ascii, ascii/text, text/ascii and text/text).
> The unit test should be added to {{OperationFctsTest}}.
> To allow for concatenating constants (eg: SELECT v1 + ' ' + v2 FROM ...) you
> will need to add a {{getPreferedTypeFor}} method to
> {{org.apache.cassandra.Constants.Type.STRING}} that determine the constant
> type based on its content (ascii or not).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17190) Add support for String contatenation through the "+" operator
Benjamin Lerer created CASSANDRA-17190:
--
Summary: Add support for String contatenation through the "+"
operator
Key: CASSANDRA-17190
URL: https://issues.apache.org/jira/browse/CASSANDRA-17190
Project: Cassandra
Issue Type: Improvement
Components: CQL/Interpreter
Reporter: Benjamin Lerer
Since 4.0, Cassandra support operations on numeric types and on some temporal
types.
We should add support for string concatenations through the {{+}} operator.
+Additional information for newcomers:+
Cassandra has 2 string types: {{Text}} ({{UTF8Type}}) and ascii
({{AsciiType}}) both are sub-classes of ({{StringType}}). In order to add
support for string concatenation you will need to add a new method to
{{StringType}} and modify {{OperationFcts}} to add the new functions (one for
each combination of types: ascii/ascii, ascii/text, text/ascii and text/text).
The unit test should be added to {{OperationFctsTest}}.
To allow for concatenating constants (eg: SELECT v1 + ' ' + v2 FROM ...) you
will need to add a {{getPreferedTypeFor}} method to
{{org.apache.cassandra.Constants.Type.STRING}} that determine the constant type
based on its content (ascii or not).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17181) SchemaCQLHelperTest methods can be simplified
[
https://issues.apache.org/jira/browse/CASSANDRA-17181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-17181:
---
Description:
{{SchemaCQLHelperTest}} is used during a snapshot to generate the
{{schema.cql}} file. The methods accept the following paramaters:
{{includeDroppedColumns}}, {{internals}} and {{ifNotExists}}.
Those parameters are in practice always set to true by the calling code and
therefore can be removed.
was:
When a schema.cql is created during a snapshot, {{CREATE TYPE}} statements are
not created with {{IF NOT EXISTS}} as the {{CREATE TABLE}} statements. This can
cause some issues when using those statements during restore.
Additional Information for newcomers:
In 3.0 and 3.11 the code use to generate the {{schema.cql}} file is in
{{TableCQLHelper}} and the unit tests in {{TableCQLHelperTest}}.
In 4.0 the bug does not exist anymore but the test {{SchemaCQLHelperTest}} does
not test the correct behavior and the code could be simplified
> SchemaCQLHelperTest methods can be simplified
> -
>
> Key: CASSANDRA-17181
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17181
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Snapshots
>Reporter: Benjamin Lerer
>Assignee: Bartlomiej
>Priority: Normal
> Labels: AdventCalendar2021, lhf
> Fix For: 4.1
>
>
> {{SchemaCQLHelperTest}} is used during a snapshot to generate the
> {{schema.cql}} file. The methods accept the following paramaters:
> {{includeDroppedColumns}}, {{internals}} and {{ifNotExists}}.
> Those parameters are in practice always set to true by the calling code and
> therefore can be removed.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-17181) SchemaCQLHelperTest methods can be simplified
[
https://issues.apache.org/jira/browse/CASSANDRA-17181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer reassigned CASSANDRA-17181:
--
Assignee: Bartlomiej
> SchemaCQLHelperTest methods can be simplified
> -
>
> Key: CASSANDRA-17181
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17181
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Snapshots
>Reporter: Benjamin Lerer
>Assignee: Bartlomiej
>Priority: Normal
> Labels: AdventCalendar2021, lhf
> Fix For: 4.1
>
>
> When a schema.cql is created during a snapshot, {{CREATE TYPE}} statements
> are not created with {{IF NOT EXISTS}} as the {{CREATE TABLE}} statements.
> This can cause some issues when using those statements during restore.
> Additional Information for newcomers:
> In 3.0 and 3.11 the code use to generate the {{schema.cql}} file is in
> {{TableCQLHelper}} and the unit tests in {{TableCQLHelperTest}}.
> In 4.0 the bug does not exist anymore but the test {{SchemaCQLHelperTest}}
> does not test the correct behavior and the code could be simplified
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17181) SchemaCQLHelperTest methods can be simplified
[
https://issues.apache.org/jira/browse/CASSANDRA-17181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-17181:
---
Fix Version/s: 4.1
(was: 3.0.x)
(was: 3.11.x)
(was: 4.0.x)
> SchemaCQLHelperTest methods can be simplified
> -
>
> Key: CASSANDRA-17181
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17181
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Snapshots
>Reporter: Benjamin Lerer
>Priority: Normal
> Labels: AdventCalendar2021, lhf
> Fix For: 4.1
>
>
> When a schema.cql is created during a snapshot, {{CREATE TYPE}} statements
> are not created with {{IF NOT EXISTS}} as the {{CREATE TABLE}} statements.
> This can cause some issues when using those statements during restore.
> Additional Information for newcomers:
> In 3.0 and 3.11 the code use to generate the {{schema.cql}} file is in
> {{TableCQLHelper}} and the unit tests in {{TableCQLHelperTest}}.
> In 4.0 the bug does not exist anymore but the test {{SchemaCQLHelperTest}}
> does not test the correct behavior and the code could be simplified
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17181) SchemaCQLHelperTest methods can be simplified
[
https://issues.apache.org/jira/browse/CASSANDRA-17181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-17181:
---
Summary: SchemaCQLHelperTest methods can be simplified (was: schema.cql
should have IF NOT EXISTS for CREATE TYPE)
> SchemaCQLHelperTest methods can be simplified
> -
>
> Key: CASSANDRA-17181
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17181
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Snapshots
>Reporter: Benjamin Lerer
>Priority: Normal
> Labels: AdventCalendar2021, lhf
> Fix For: 3.0.x, 3.11.x, 4.0.x
>
>
> When a schema.cql is created during a snapshot, {{CREATE TYPE}} statements
> are not created with {{IF NOT EXISTS}} as the {{CREATE TABLE}} statements.
> This can cause some issues when using those statements during restore.
> Additional Information for newcomers:
> In 3.0 and 3.11 the code use to generate the {{schema.cql}} file is in
> {{TableCQLHelper}} and the unit tests in {{TableCQLHelperTest}}.
> In 4.0 the bug does not exist anymore but the test {{SchemaCQLHelperTest}}
> does not test the correct behavior and the code could be simplified
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17181) schema.cql should have IF NOT EXISTS for CREATE TYPE
[
https://issues.apache.org/jira/browse/CASSANDRA-17181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17453946#comment-17453946
]
Benjamin Lerer commented on CASSANDRA-17181:
[~bkowalczyyk] You are right. I was looking at a snapshot of the code from when
CASSANDRA-14825 was committed (shame on me). To make the matter worst, I was
reviewer of the fix CASSANDRA-13935 :-(. All my apologizes for that.
So the problem is fixed but looking at the 4.0 code it seems that the
{{SchemaCQLHelper}} methods are having a set of boolean parameters that are
never used (as I would have expected) as they are always called with {{true}}.
The only call that do not use true seems to be a useless one.
If you are interested in cleaning that I can update the ticket to reflect the
new goal (or create a new one). Otherwise I am sure that can I find you
something else to play with :-)
> schema.cql should have IF NOT EXISTS for CREATE TYPE
>
>
> Key: CASSANDRA-17181
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17181
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Snapshots
>Reporter: Benjamin Lerer
>Priority: Normal
> Labels: AdventCalendar2021, lhf
> Fix For: 3.0.x, 3.11.x, 4.0.x
>
>
> When a schema.cql is created during a snapshot, {{CREATE TYPE}} statements
> are not created with {{IF NOT EXISTS}} as the {{CREATE TABLE}} statements.
> This can cause some issues when using those statements during restore.
> Additional Information for newcomers:
> In 3.0 and 3.11 the code use to generate the {{schema.cql}} file is in
> {{TableCQLHelper}} and the unit tests in {{TableCQLHelperTest}}.
> In 4.0 the bug does not exist anymore but the test {{SchemaCQLHelperTest}}
> does not test the correct behavior and the code could be simplified
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-17181) schema.cql should have IF NOT EXISTS for CREATE TYPE
[
https://issues.apache.org/jira/browse/CASSANDRA-17181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer reassigned CASSANDRA-17181:
--
Assignee: (was: Benjamin Lerer)
> schema.cql should have IF NOT EXISTS for CREATE TYPE
>
>
> Key: CASSANDRA-17181
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17181
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Snapshots
>Reporter: Benjamin Lerer
>Priority: Normal
> Labels: AdventCalendar2021, lhf
> Fix For: 3.0.x, 3.11.x, 4.0.x
>
>
> When a schema.cql is created during a snapshot, {{CREATE TYPE}} statements
> are not created with {{IF NOT EXISTS}} as the {{CREATE TABLE}} statements.
> This can cause some issues when using those statements during restore.
> Additional Information for newcomers:
> In 3.0 and 3.11 the code use to generate the {{schema.cql}} file is in
> {{TableCQLHelper}} and the unit tests in {{TableCQLHelperTest}}.
> In 4.0 the bug does not exist anymore but the test {{SchemaCQLHelperTest}}
> does not test the correct behavior and the code could be simplified
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-17181) schema.cql should have IF NOT EXISTS for CREATE TYPE
[
https://issues.apache.org/jira/browse/CASSANDRA-17181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer reassigned CASSANDRA-17181:
--
Assignee: Benjamin Lerer
> schema.cql should have IF NOT EXISTS for CREATE TYPE
>
>
> Key: CASSANDRA-17181
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17181
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Snapshots
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
> Labels: AdventCalendar2021, lhf
> Fix For: 3.0.x, 3.11.x, 4.0.x
>
>
> When a schema.cql is created during a snapshot, {{CREATE TYPE}} statements
> are not created with {{IF NOT EXISTS}} as the {{CREATE TABLE}} statements.
> This can cause some issues when using those statements during restore.
> Additional Information for newcomers:
> In 3.0 and 3.11 the code use to generate the {{schema.cql}} file is in
> {{TableCQLHelper}} and the unit tests in {{TableCQLHelperTest}}.
> In 4.0 the bug does not exist anymore but the test {{SchemaCQLHelperTest}}
> does not test the correct behavior and the code could be simplified
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-17181) schema.cql should have IF NOT EXISTS for CREATE TYPE
[
https://issues.apache.org/jira/browse/CASSANDRA-17181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer reassigned CASSANDRA-17181:
--
Assignee: (was: Bartlomiej)
> schema.cql should have IF NOT EXISTS for CREATE TYPE
>
>
> Key: CASSANDRA-17181
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17181
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Snapshots
>Reporter: Benjamin Lerer
>Priority: Normal
> Labels: AdventCalendar2021, lhf
> Fix For: 3.0.x, 3.11.x, 4.0.x
>
>
> When a schema.cql is created during a snapshot, {{CREATE TYPE}} statements
> are not created with {{IF NOT EXISTS}} as the {{CREATE TABLE}} statements.
> This can cause some issues when using those statements during restore.
> Additional Information for newcomers:
> In 3.0 and 3.11 the code use to generate the {{schema.cql}} file is in
> {{TableCQLHelper}} and the unit tests in {{TableCQLHelperTest}}.
> In 4.0 the bug does not exist anymore but the test {{SchemaCQLHelperTest}}
> does not test the correct behavior and the code could be simplified
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-17181) schema.cql should have IF NOT EXISTS for CREATE TYPE
[
https://issues.apache.org/jira/browse/CASSANDRA-17181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer reassigned CASSANDRA-17181:
--
Assignee: Bartlomiej
> schema.cql should have IF NOT EXISTS for CREATE TYPE
>
>
> Key: CASSANDRA-17181
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17181
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Snapshots
>Reporter: Benjamin Lerer
>Assignee: Bartlomiej
>Priority: Normal
> Labels: AdventCalendar2021, lhf
> Fix For: 3.0.x, 3.11.x, 4.0.x
>
>
> When a schema.cql is created during a snapshot, {{CREATE TYPE}} statements
> are not created with {{IF NOT EXISTS}} as the {{CREATE TABLE}} statements.
> This can cause some issues when using those statements during restore.
> Additional Information for newcomers:
> In 3.0 and 3.11 the code use to generate the {{schema.cql}} file is in
> {{TableCQLHelper}} and the unit tests in {{TableCQLHelperTest}}.
> In 4.0 the bug does not exist anymore but the test {{SchemaCQLHelperTest}}
> does not test the correct behavior and the code could be simplified
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16436) Add startup check for large read_ahead_kb setting
[
https://issues.apache.org/jira/browse/CASSANDRA-16436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-16436:
---
Mentor: Paulo Motta
> Add startup check for large read_ahead_kb setting
> -
>
> Key: CASSANDRA-16436
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16436
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Startup and Shutdown
>Reporter: Paulo Motta
>Priority: Normal
> Labels: AdventCalendar2021, lhf
>
> A well known production tuning recommendation is to dial back the
> {{read_ahead_kb}} Linux setting from the default of 4096 in most
> distributions as this can cause high IO usage and cache churn on
> read-intensive workloads.
> We should add a startup warning to detect when a high {{read_ahead_kb}} is
> used and recommend the user to dial back to a reasonable value, which varies
> according to the workload but a general guideline is to tune this to 8kb.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-7662) Implement templated CREATE TABLE functionality (CREATE TABLE LIKE)
[ https://issues.apache.org/jira/browse/CASSANDRA-7662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Lerer updated CASSANDRA-7662: -- Mentor: Benjamin Lerer > Implement templated CREATE TABLE functionality (CREATE TABLE LIKE) > -- > > Key: CASSANDRA-7662 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7662 > Project: Cassandra > Issue Type: New Feature > Components: Legacy/CQL >Reporter: Aleksey Yeschenko >Priority: Low > Labels: AdventCalendar2021, lhf > Fix For: 4.x > > Attachments: 7662.patch, CASSANDRA-7662.patch > > > Implement templated CREATE TABLE functionality (CREATE TABLE LIKE) to > simplify creating new tables duplicating existing ones (see parent_table part > of http://www.postgresql.org/docs/9.1/static/sql-createtable.html). > CREATE TABLE LIKE ; - would create a new table with > the same columns and options as > +Additional info for newcomers:+ > In order to implement this change you will need to change the Parser.g ANTLR > file located in the src/antlr directory and the java classes corresponding to > the CREATE statement located in the > org.apache.cassandra.cql3.statements.schema package. > The unit test for the CQL logic are located under > org.apache.cassandra.cql3.validation > cqlsh parsing will need to be modified to support the new LIKE syntax. The > logic is in pylib/cqlshlib/cql3handling.py and the test in > pylib/cqlshlib/test/test_cqlsh_completion.py -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14879) Log DDL statements on coordinator
[
https://issues.apache.org/jira/browse/CASSANDRA-14879?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-14879:
---
Description:
People sometimes run into issues with schema, and that is often because they do
concurrent schema changes, which are just not supported and we should fix that
someday, but in the meantime, it's not always easy to even check if you may
indeed have had concurrent schema changes.
A very trivial way to make that easier would be to simply log DDL statements on
the coordinator before they are executed. This is likely useful info for
operators in the first place, and would allow in most case to track if
concurrent schema was the likely cause of a particular issue seen.
+Additional info for newcomers:+
In order to implement this change you will need to modify
{{org.apache.cassandra.cql3.QueryProcessor}} to log the schema change before it
is executed.
was:
People sometimes run into issues with schema, and that is often because they do
concurrent schema changes, which are just not supported and we should fix that
someday, but in the meantime, it's not always easy to even check if you may
indeed have had concurrent schema changes.
A very trivial way to make that easier would be to simply log DDL statements on
the coordinator before they are executed. This is likely useful info for
operators in the first place, and would allow in most case to track if
concurrent schema was the likely cause of a particular issue seen.
> Log DDL statements on coordinator
> -
>
> Key: CASSANDRA-14879
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14879
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/CQL
>Reporter: Sylvain Lebresne
>Priority: Low
> Labels: AdventCalendar2021, lhf
> Fix For: 4.x
>
>
> People sometimes run into issues with schema, and that is often because they
> do concurrent schema changes, which are just not supported and we should fix
> that someday, but in the meantime, it's not always easy to even check if you
> may indeed have had concurrent schema changes.
> A very trivial way to make that easier would be to simply log DDL statements
> on the coordinator before they are executed. This is likely useful info for
> operators in the first place, and would allow in most case to track if
> concurrent schema was the likely cause of a particular issue seen.
> +Additional info for newcomers:+
> In order to implement this change you will need to modify
> {{org.apache.cassandra.cql3.QueryProcessor}} to log the schema change before
> it is executed.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14879) Log DDL statements on coordinator
[
https://issues.apache.org/jira/browse/CASSANDRA-14879?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-14879:
---
Mentor: Benjamin Lerer
> Log DDL statements on coordinator
> -
>
> Key: CASSANDRA-14879
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14879
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/CQL
>Reporter: Sylvain Lebresne
>Priority: Low
> Labels: AdventCalendar2021, lhf
> Fix For: 4.x
>
>
> People sometimes run into issues with schema, and that is often because they
> do concurrent schema changes, which are just not supported and we should fix
> that someday, but in the meantime, it's not always easy to even check if you
> may indeed have had concurrent schema changes.
> A very trivial way to make that easier would be to simply log DDL statements
> on the coordinator before they are executed. This is likely useful info for
> operators in the first place, and would allow in most case to track if
> concurrent schema was the likely cause of a particular issue seen.
> +Additional info for newcomers:+
> In order to implement this change you will need to modify
> {{org.apache.cassandra.cql3.QueryProcessor}} to log the schema change before
> it is executed.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14879) Log DDL statements on coordinator
[ https://issues.apache.org/jira/browse/CASSANDRA-14879?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Lerer updated CASSANDRA-14879: --- Complexity: Low Hanging Fruit > Log DDL statements on coordinator > - > > Key: CASSANDRA-14879 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14879 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/CQL >Reporter: Sylvain Lebresne >Priority: Low > Labels: AdventCalendar2021, lhf > Fix For: 4.x > > > People sometimes run into issues with schema, and that is often because they > do concurrent schema changes, which are just not supported and we should fix > that someday, but in the meantime, it's not always easy to even check if you > may indeed have had concurrent schema changes. > A very trivial way to make that easier would be to simply log DDL statements > on the coordinator before they are executed. This is likely useful info for > operators in the first place, and would allow in most case to track if > concurrent schema was the likely cause of a particular issue seen. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-14879) Log DDL statements on coordinator
[ https://issues.apache.org/jira/browse/CASSANDRA-14879?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Lerer reassigned CASSANDRA-14879: -- Assignee: (was: Sylvain Lebresne) > Log DDL statements on coordinator > - > > Key: CASSANDRA-14879 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14879 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/CQL >Reporter: Sylvain Lebresne >Priority: Low > Fix For: 4.x > > > People sometimes run into issues with schema, and that is often because they > do concurrent schema changes, which are just not supported and we should fix > that someday, but in the meantime, it's not always easy to even check if you > may indeed have had concurrent schema changes. > A very trivial way to make that easier would be to simply log DDL statements > on the coordinator before they are executed. This is likely useful info for > operators in the first place, and would allow in most case to track if > concurrent schema was the likely cause of a particular issue seen. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14879) Log DDL statements on coordinator
[ https://issues.apache.org/jira/browse/CASSANDRA-14879?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Lerer updated CASSANDRA-14879: --- Labels: AdventCalendar2021 lhf (was: ) > Log DDL statements on coordinator > - > > Key: CASSANDRA-14879 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14879 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/CQL >Reporter: Sylvain Lebresne >Priority: Low > Labels: AdventCalendar2021, lhf > Fix For: 4.x > > > People sometimes run into issues with schema, and that is often because they > do concurrent schema changes, which are just not supported and we should fix > that someday, but in the meantime, it's not always easy to even check if you > may indeed have had concurrent schema changes. > A very trivial way to make that easier would be to simply log DDL statements > on the coordinator before they are executed. This is likely useful info for > operators in the first place, and would allow in most case to track if > concurrent schema was the likely cause of a particular issue seen. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14879) Log DDL statements on coordinator
[ https://issues.apache.org/jira/browse/CASSANDRA-14879?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Lerer updated CASSANDRA-14879: --- Fix Version/s: 4.x > Log DDL statements on coordinator > - > > Key: CASSANDRA-14879 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14879 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/CQL >Reporter: Sylvain Lebresne >Assignee: Sylvain Lebresne >Priority: Low > Fix For: 4.x > > > People sometimes run into issues with schema, and that is often because they > do concurrent schema changes, which are just not supported and we should fix > that someday, but in the meantime, it's not always easy to even check if you > may indeed have had concurrent schema changes. > A very trivial way to make that easier would be to simply log DDL statements > on the coordinator before they are executed. This is likely useful info for > operators in the first place, and would allow in most case to track if > concurrent schema was the likely cause of a particular issue seen. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-7662) Implement templated CREATE TABLE functionality (CREATE TABLE LIKE)
[ https://issues.apache.org/jira/browse/CASSANDRA-7662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Lerer updated CASSANDRA-7662: -- Labels: AdventCalendar2021 lhf (was: AdventCalendar2021) > Implement templated CREATE TABLE functionality (CREATE TABLE LIKE) > -- > > Key: CASSANDRA-7662 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7662 > Project: Cassandra > Issue Type: New Feature > Components: Legacy/CQL >Reporter: Aleksey Yeschenko >Priority: Low > Labels: AdventCalendar2021, lhf > Fix For: 4.x > > Attachments: 7662.patch, CASSANDRA-7662.patch > > > Implement templated CREATE TABLE functionality (CREATE TABLE LIKE) to > simplify creating new tables duplicating existing ones (see parent_table part > of http://www.postgresql.org/docs/9.1/static/sql-createtable.html). > CREATE TABLE LIKE ; - would create a new table with > the same columns and options as > +Additional info for newcomers:+ > In order to implement this change you will need to change the Parser.g ANTLR > file located in the src/antlr directory and the java classes corresponding to > the CREATE statement located in the > org.apache.cassandra.cql3.statements.schema package. > The unit test for the CQL logic are located under > org.apache.cassandra.cql3.validation > cqlsh parsing will need to be modified to support the new LIKE syntax. The > logic is in pylib/cqlshlib/cql3handling.py and the test in > pylib/cqlshlib/test/test_cqlsh_completion.py -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17184) Add += and -= syntax to ALTER TABLE WITH
[
https://issues.apache.org/jira/browse/CASSANDRA-17184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-17184:
---
Labels: AdventCalendar2021 lhf (was: AdventCalendar2021)
> Add += and -= syntax to ALTER TABLE WITH
>
>
> Key: CASSANDRA-17184
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17184
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Syntax
>Reporter: Benjamin Lerer
>Priority: Normal
> Labels: AdventCalendar2021, lhf
> Fix For: 4.x
>
>
> We have 2 types of table properties in CQL: simple ones (comment,
> gc_grace_seconds, ...), which are basically of type text (even if, we
> historically allow constants of any type) and complex ones (compaction,
> caching...), which are basically map.
> The only syntax that {{ALTER TABLE WITH}} supports is of setting a property,
> and so for the later kind, we basically always have to provide the new full
> map for the option. To take an example, say you have a table with compaction
> and want to enable compaction logging you will have to provide the all map.
> In order to avoid that problem we can add support for the {{+=}} (and {{-=}}
> ideally) syntax that already exists for maps otherwise, and support:
> {code}
> ALTER TABLE t WITH compaction+= { 'log_all' : 'true' }
> {code}
> +Additional info for newcomers:+
> In order to implement this change you will need to change the Parser.g ANTLR
> file located in the src/antlr directory and the java classes corresponding to
> the different alter statements located in the
> {{org.apache.cassandra.cql3.statements.schema}} package.
> The unit test for the CQL logic are located under
> {{org.apache.cassandra.cql3.validation}}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17181) schema.cql should have IF NOT EXISTS for CREATE TYPE
[
https://issues.apache.org/jira/browse/CASSANDRA-17181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-17181:
---
Labels: AdventCalendar2021 lhf (was: AdventCalendar2021)
> schema.cql should have IF NOT EXISTS for CREATE TYPE
>
>
> Key: CASSANDRA-17181
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17181
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Snapshots
>Reporter: Benjamin Lerer
>Priority: Normal
> Labels: AdventCalendar2021, lhf
> Fix For: 3.0.x, 3.11.x, 4.0.x
>
>
> When a schema.cql is created during a snapshot, {{CREATE TYPE}} statements
> are not created with {{IF NOT EXISTS}} as the {{CREATE TABLE}} statements.
> This can cause some issues when using those statements during restore.
> Additional Information for newcomers:
> In 3.0 and 3.11 the code use to generate the {{schema.cql}} file is in
> {{TableCQLHelper}} and the unit tests in {{TableCQLHelperTest}}.
> In 4.0 the bug does not exist anymore but the test {{SchemaCQLHelperTest}}
> does not test the correct behavior and the code could be simplified
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16436) Add startup check for large read_ahead_kb setting
[
https://issues.apache.org/jira/browse/CASSANDRA-16436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-16436:
---
Labels: AdventCalendar2021 lhf (was: lhf)
> Add startup check for large read_ahead_kb setting
> -
>
> Key: CASSANDRA-16436
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16436
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Startup and Shutdown
>Reporter: Paulo Motta
>Priority: Normal
> Labels: AdventCalendar2021, lhf
>
> A well known production tuning recommendation is to dial back the
> {{read_ahead_kb}} Linux setting from the default of 4096 in most
> distributions as this can cause high IO usage and cache churn on
> read-intensive workloads.
> We should add a startup warning to detect when a high {{read_ahead_kb}} is
> used and recommend the user to dial back to a reasonable value, which varies
> according to the workload but a general guideline is to tune this to 8kb.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-16436) Add startup check for large read_ahead_kb setting
[
https://issues.apache.org/jira/browse/CASSANDRA-16436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer reassigned CASSANDRA-16436:
--
Assignee: (was: Owen Qian)
> Add startup check for large read_ahead_kb setting
> -
>
> Key: CASSANDRA-16436
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16436
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Startup and Shutdown
>Reporter: Paulo Motta
>Priority: Normal
> Labels: lhf
>
> A well known production tuning recommendation is to dial back the
> {{read_ahead_kb}} Linux setting from the default of 4096 in most
> distributions as this can cause high IO usage and cache churn on
> read-intensive workloads.
> We should add a startup warning to detect when a high {{read_ahead_kb}} is
> used and recommend the user to dial back to a reasonable value, which varies
> according to the workload but a general guideline is to tune this to 8kb.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-7662) Implement templated CREATE TABLE functionality (CREATE TABLE LIKE)
[ https://issues.apache.org/jira/browse/CASSANDRA-7662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Lerer updated CASSANDRA-7662: -- Labels: AdventCalendar2021 (was: ) > Implement templated CREATE TABLE functionality (CREATE TABLE LIKE) > -- > > Key: CASSANDRA-7662 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7662 > Project: Cassandra > Issue Type: New Feature > Components: Legacy/CQL >Reporter: Aleksey Yeschenko >Priority: Low > Labels: AdventCalendar2021 > Fix For: 4.x > > Attachments: 7662.patch, CASSANDRA-7662.patch > > > Implement templated CREATE TABLE functionality (CREATE TABLE LIKE) to > simplify creating new tables duplicating existing ones (see parent_table part > of http://www.postgresql.org/docs/9.1/static/sql-createtable.html). > CREATE TABLE LIKE ; - would create a new table with > the same columns and options as > +Additional info for newcomers:+ > In order to implement this change you will need to change the Parser.g ANTLR > file located in the src/antlr directory and the java classes corresponding to > the CREATE statement located in the > org.apache.cassandra.cql3.statements.schema package. > The unit test for the CQL logic are located under > org.apache.cassandra.cql3.validation > cqlsh parsing will need to be modified to support the new LIKE syntax. The > logic is in pylib/cqlshlib/cql3handling.py and the test in > pylib/cqlshlib/test/test_cqlsh_completion.py -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-7662) Implement templated CREATE TABLE functionality (CREATE TABLE LIKE)
[ https://issues.apache.org/jira/browse/CASSANDRA-7662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Lerer updated CASSANDRA-7662: -- Description: Implement templated CREATE TABLE functionality (CREATE TABLE LIKE) to simplify creating new tables duplicating existing ones (see parent_table part of http://www.postgresql.org/docs/9.1/static/sql-createtable.html). CREATE TABLE LIKE ; - would create a new table with the same columns and options as +Additional info for newcomers:+ In order to implement this change you will need to change the Parser.g ANTLR file located in the src/antlr directory and the java classes corresponding to the CREATE statement located in the org.apache.cassandra.cql3.statements.schema package. The unit test for the CQL logic are located under org.apache.cassandra.cql3.validation cqlsh parsing will need to be modified to support the new LIKE syntax. The logic is in pylib/cqlshlib/cql3handling.py and the test in pylib/cqlshlib/test/test_cqlsh_completion.py was: Implement templated CREATE TABLE functionality (CREATE TABLE LIKE) to simplify creating new tables duplicating existing ones (see parent_table part of http://www.postgresql.org/docs/9.1/static/sql-createtable.html). CREATE TABLE LIKE ; - would create a new table with the same columns and options as > Implement templated CREATE TABLE functionality (CREATE TABLE LIKE) > -- > > Key: CASSANDRA-7662 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7662 > Project: Cassandra > Issue Type: New Feature > Components: Legacy/CQL >Reporter: Aleksey Yeschenko >Priority: Low > Fix For: 4.x > > Attachments: 7662.patch, CASSANDRA-7662.patch > > > Implement templated CREATE TABLE functionality (CREATE TABLE LIKE) to > simplify creating new tables duplicating existing ones (see parent_table part > of http://www.postgresql.org/docs/9.1/static/sql-createtable.html). > CREATE TABLE LIKE ; - would create a new table with > the same columns and options as > +Additional info for newcomers:+ > In order to implement this change you will need to change the Parser.g ANTLR > file located in the src/antlr directory and the java classes corresponding to > the CREATE statement located in the > org.apache.cassandra.cql3.statements.schema package. > The unit test for the CQL logic are located under > org.apache.cassandra.cql3.validation > cqlsh parsing will need to be modified to support the new LIKE syntax. The > logic is in pylib/cqlshlib/cql3handling.py and the test in > pylib/cqlshlib/test/test_cqlsh_completion.py -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-7662) Implement templated CREATE TABLE functionality (CREATE TABLE LIKE)
[ https://issues.apache.org/jira/browse/CASSANDRA-7662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Lerer updated CASSANDRA-7662: -- Complexity: Low Hanging Fruit Reviewers: Benjamin Lerer > Implement templated CREATE TABLE functionality (CREATE TABLE LIKE) > -- > > Key: CASSANDRA-7662 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7662 > Project: Cassandra > Issue Type: New Feature > Components: Legacy/CQL >Reporter: Aleksey Yeschenko >Priority: Low > Fix For: 4.x > > Attachments: 7662.patch, CASSANDRA-7662.patch > > > Implement templated CREATE TABLE functionality (CREATE TABLE LIKE) to > simplify creating new tables duplicating existing ones (see parent_table part > of http://www.postgresql.org/docs/9.1/static/sql-createtable.html). > CREATE TABLE LIKE ; - would create a new table with > the same columns and options as > +Additional info for newcomers:+ > In order to implement this change you will need to change the Parser.g ANTLR > file located in the src/antlr directory and the java classes corresponding to > the CREATE statement located in the > org.apache.cassandra.cql3.statements.schema package. > The unit test for the CQL logic are located under > org.apache.cassandra.cql3.validation > cqlsh parsing will need to be modified to support the new LIKE syntax. The > logic is in pylib/cqlshlib/cql3handling.py and the test in > pylib/cqlshlib/test/test_cqlsh_completion.py -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17184) Add += and -= syntax to ALTER TABLE WITH
[
https://issues.apache.org/jira/browse/CASSANDRA-17184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-17184:
---
Labels: AdventCalendar2021 (was: )
> Add += and -= syntax to ALTER TABLE WITH
>
>
> Key: CASSANDRA-17184
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17184
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Syntax
>Reporter: Benjamin Lerer
>Priority: Normal
> Labels: AdventCalendar2021
> Fix For: 4.x
>
>
> We have 2 types of table properties in CQL: simple ones (comment,
> gc_grace_seconds, ...), which are basically of type text (even if, we
> historically allow constants of any type) and complex ones (compaction,
> caching...), which are basically map.
> The only syntax that {{ALTER TABLE WITH}} supports is of setting a property,
> and so for the later kind, we basically always have to provide the new full
> map for the option. To take an example, say you have a table with compaction
> and want to enable compaction logging you will have to provide the all map.
> In order to avoid that problem we can add support for the {{+=}} (and {{-=}}
> ideally) syntax that already exists for maps otherwise, and support:
> {code}
> ALTER TABLE t WITH compaction+= { 'log_all' : 'true' }
> {code}
> +Additional info for newcomers:+
> In order to implement this change you will need to change the Parser.g ANTLR
> file located in the src/antlr directory and the java classes corresponding to
> the different alter statements located in the
> {{org.apache.cassandra.cql3.statements.schema}} package.
> The unit test for the CQL logic are located under
> {{org.apache.cassandra.cql3.validation}}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17184) Add += and -= syntax to ALTER TABLE WITH
[
https://issues.apache.org/jira/browse/CASSANDRA-17184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-17184:
---
Description:
We have 2 types of table properties in CQL: simple ones (comment,
gc_grace_seconds, ...), which are basically of type text (even if, we
historically allow constants of any type) and complex ones (compaction,
caching...), which are basically map.
The only syntax that {{ALTER TABLE WITH}} supports is of setting a property,
and so for the later kind, we basically always have to provide the new full map
for the option. To take an example, say you have a table with compaction and
want to enable compaction logging you will have to provide the all map.
In order to avoid that problem we can add support for the {{+=}} (and {{-=}}
ideally) syntax that already exists for maps otherwise, and support:
{code}
ALTER TABLE t WITH compaction+= { 'log_all' : 'true' }
{code}
+Additional info for newcomers:+
In order to implement this change you will need to change the Parser.g ANTLR
file located in the src/antlr directory and the java classes corresponding to
the different alter statements located in the
{{org.apache.cassandra.cql3.statements.schema}} package.
The unit test for the CQL logic are located under
{{org.apache.cassandra.cql3.validation}}
was:
We have 2 types of table properties in CQL: simple ones (comment,
gc_grace_seconds, ...), which are basically of type text (even if, we
historically allow constants of any type) and complex ones (compaction,
caching...), which are basically map.
The only syntax that {{ALTER TABLE WITH}} supports is of setting a property,
and so for the later kind, we basically always have to provide the new full map
for the option. To take an example, say you have a table with compaction and
want to enable compaction logging you will have to provide the all map.
In order to avoid that problem we can add support for the {{+=}} (and {{-=}}
ideally) syntax that already exists for maps otherwise, and support:
{code}
ALTER TABLE t WITH compaction+= \{ 'log_all' : 'true' \}
{code}
+Additional info for newcomers:+
In order to implement this change you will need to change the Parser.g ANTLR
file located in the src/antlr directory and the java classes corresponding to
the different alter statements located in the
{{org.apache.cassandra.cql3.statements.schema}} package.
The unit test for the CQL logic are located under
{{org.apache.cassandra.cql3.validation}}
> Add += and -= syntax to ALTER TABLE WITH
>
>
> Key: CASSANDRA-17184
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17184
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Syntax
>Reporter: Benjamin Lerer
>Priority: Normal
>
> We have 2 types of table properties in CQL: simple ones (comment,
> gc_grace_seconds, ...), which are basically of type text (even if, we
> historically allow constants of any type) and complex ones (compaction,
> caching...), which are basically map.
> The only syntax that {{ALTER TABLE WITH}} supports is of setting a property,
> and so for the later kind, we basically always have to provide the new full
> map for the option. To take an example, say you have a table with compaction
> and want to enable compaction logging you will have to provide the all map.
> In order to avoid that problem we can add support for the {{+=}} (and {{-=}}
> ideally) syntax that already exists for maps otherwise, and support:
> {code}
> ALTER TABLE t WITH compaction+= { 'log_all' : 'true' }
> {code}
> +Additional info for newcomers:+
> In order to implement this change you will need to change the Parser.g ANTLR
> file located in the src/antlr directory and the java classes corresponding to
> the different alter statements located in the
> {{org.apache.cassandra.cql3.statements.schema}} package.
> The unit test for the CQL logic are located under
> {{org.apache.cassandra.cql3.validation}}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17184) Add += and -= syntax to ALTER TABLE WITH
[
https://issues.apache.org/jira/browse/CASSANDRA-17184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-17184:
---
Change Category: Operability
Complexity: Low Hanging Fruit
Fix Version/s: 4.x
Status: Open (was: Triage Needed)
> Add += and -= syntax to ALTER TABLE WITH
>
>
> Key: CASSANDRA-17184
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17184
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Syntax
>Reporter: Benjamin Lerer
>Priority: Normal
> Fix For: 4.x
>
>
> We have 2 types of table properties in CQL: simple ones (comment,
> gc_grace_seconds, ...), which are basically of type text (even if, we
> historically allow constants of any type) and complex ones (compaction,
> caching...), which are basically map.
> The only syntax that {{ALTER TABLE WITH}} supports is of setting a property,
> and so for the later kind, we basically always have to provide the new full
> map for the option. To take an example, say you have a table with compaction
> and want to enable compaction logging you will have to provide the all map.
> In order to avoid that problem we can add support for the {{+=}} (and {{-=}}
> ideally) syntax that already exists for maps otherwise, and support:
> {code}
> ALTER TABLE t WITH compaction+= { 'log_all' : 'true' }
> {code}
> +Additional info for newcomers:+
> In order to implement this change you will need to change the Parser.g ANTLR
> file located in the src/antlr directory and the java classes corresponding to
> the different alter statements located in the
> {{org.apache.cassandra.cql3.statements.schema}} package.
> The unit test for the CQL logic are located under
> {{org.apache.cassandra.cql3.validation}}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17184) Add += and -= syntax to ALTER TABLE WITH
[
https://issues.apache.org/jira/browse/CASSANDRA-17184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-17184:
---
Description:
We have 2 types of table properties in CQL: simple ones (comment,
gc_grace_seconds, ...), which are basically of type text (even if, we
historically allow constants of any type) and complex ones (compaction,
caching...), which are basically map.
The only syntax that {{ALTER TABLE WITH}} supports is of setting a property,
and so for the later kind, we basically always have to provide the new full map
for the option. To take an example, say you have a table with compaction and
want to enable compaction logging you will have to provide the all map.
In order to avoid that problem we can add support for the {{+=}} (and {{-=}}
ideally) syntax that already exists for maps otherwise, and support:
{code}
ALTER TABLE t WITH compaction+= \{ 'log_all' : 'true' \}
{code}
+Additional info for newcomers:+
In order to implement this change you will need to change the Parser.g ANTLR
file located in the src/antlr directory and the java classes corresponding to
the different alter statements located in the
{{org.apache.cassandra.cql3.statements.schema}} package.
The unit test for the CQL logic are located under
{{org.apache.cassandra.cql3.validation}}
was:
We have 2 types of table properties in CQL: simple ones (comment,
gc_grace_seconds, ...), which are basically of type text (even if, we
historically allow constants of any type) and complex ones (compaction,
caching...), which are basically map.
The only syntax that {{ALTER TABLE WITH}} supports is of setting a property,
and so for the later kind, we basically always have to provide the new full map
for the option. To take an example, say you have a table with compaction and
want to enable compaction logging you will have to provide the all map.
In order to avoid that problem we can add support for the {{+=}} (and {{-=}}
ideally) syntax that already exists for maps otherwise, and support:
{{ALTER TABLE t WITH compaction+= \{ 'log_all' : 'true' \}}}
+Additional info for newcomers:+
In order to implement this change you will need to change the Parser.g ANTLR
file located in the src/antlr directory and the java classes corresponding to
the different alter statements located in the
{{org.apache.cassandra.cql3.statements.schema}} package.
The unit test for the CQL logic are located under
{{org.apache.cassandra.cql3.validation}}
> Add += and -= syntax to ALTER TABLE WITH
>
>
> Key: CASSANDRA-17184
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17184
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Syntax
>Reporter: Benjamin Lerer
>Priority: Normal
>
> We have 2 types of table properties in CQL: simple ones (comment,
> gc_grace_seconds, ...), which are basically of type text (even if, we
> historically allow constants of any type) and complex ones (compaction,
> caching...), which are basically map.
> The only syntax that {{ALTER TABLE WITH}} supports is of setting a property,
> and so for the later kind, we basically always have to provide the new full
> map for the option. To take an example, say you have a table with compaction
> and want to enable compaction logging you will have to provide the all map.
> In order to avoid that problem we can add support for the {{+=}} (and {{-=}}
> ideally) syntax that already exists for maps otherwise, and support:
> {code}
> ALTER TABLE t WITH compaction+= \{ 'log_all' : 'true' \}
> {code}
> +Additional info for newcomers:+
> In order to implement this change you will need to change the Parser.g ANTLR
> file located in the src/antlr directory and the java classes corresponding to
> the different alter statements located in the
> {{org.apache.cassandra.cql3.statements.schema}} package.
> The unit test for the CQL logic are located under
> {{org.apache.cassandra.cql3.validation}}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17184) Add += and -= syntax to ALTER TABLE WITH
[
https://issues.apache.org/jira/browse/CASSANDRA-17184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-17184:
---
Description:
We have 2 types of table properties in CQL: simple ones (comment,
gc_grace_seconds, ...), which are basically of type text (even if, we
historically allow constants of any type) and complex ones (compaction,
caching...), which are basically map.
The only syntax that {{ALTER TABLE WITH}} supports is of setting a property,
and so for the later kind, we basically always have to provide the new full map
for the option. To take an example, say you have a table with compaction and
want to enable compaction logging you will have to provide the all map.
In order to avoid that problem we can add support for the {{+=}} (and {{-=}}
ideally) syntax that already exists for maps otherwise, and support:
{{ALTER TABLE t WITH compaction+= \{ 'log_all' : 'true' \}}}
+Additional info for newcomers:+
In order to implement this change you will need to change the Parser.g ANTLR
file located in the src/antlr directory and the java classes corresponding to
the different alter statements located in the
{{org.apache.cassandra.cql3.statements.schema}} package.
The unit test for the CQL logic are located under
{{org.apache.cassandra.cql3.validation}}
was:
We have 2 types of table properties in CQL: simple ones (comment,
gc_grace_seconds, ...), which are basically of type text (even if, we
historically allow constants of any type) and complex ones (compaction,
caching...), which are basically map.
The only syntax that {{ALTER TABLE WITH}} supports is of setting a property,
and so for the later kind, we basically always have to provide the new full map
for the option. To take an example, say you have a table with compaction and
want to enable compaction logging you will have to provide the all map.
+Additional info for newcomers:+
In order to implement this change you will need to change the Parser.g ANTLR
file located in the src/antlr directory and the java classes corresponding to
the different alter statements located in the
{{org.apache.cassandra.cql3.statements.schema}} package.
The unit test for the CQL logic are located under
{{org.apache.cassandra.cql3.validation}}
In order to avoid that problem we can add support for the {{+=}} (and {{-=}}
ideally) syntax that already exists for maps otherwise, and support:
{{ALTER TABLE t WITH compaction+= \{ 'log_all' : 'true' \}}}
> Add += and -= syntax to ALTER TABLE WITH
>
>
> Key: CASSANDRA-17184
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17184
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Syntax
>Reporter: Benjamin Lerer
>Priority: Normal
>
> We have 2 types of table properties in CQL: simple ones (comment,
> gc_grace_seconds, ...), which are basically of type text (even if, we
> historically allow constants of any type) and complex ones (compaction,
> caching...), which are basically map.
> The only syntax that {{ALTER TABLE WITH}} supports is of setting a property,
> and so for the later kind, we basically always have to provide the new full
> map for the option. To take an example, say you have a table with compaction
> and want to enable compaction logging you will have to provide the all map.
> In order to avoid that problem we can add support for the {{+=}} (and {{-=}}
> ideally) syntax that already exists for maps otherwise, and support:
> {{ALTER TABLE t WITH compaction+= \{ 'log_all' : 'true' \}}}
> +Additional info for newcomers:+
> In order to implement this change you will need to change the Parser.g ANTLR
> file located in the src/antlr directory and the java classes corresponding to
> the different alter statements located in the
> {{org.apache.cassandra.cql3.statements.schema}} package.
> The unit test for the CQL logic are located under
> {{org.apache.cassandra.cql3.validation}}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17184) Add += and -= syntax to ALTER TABLE WITH
Benjamin Lerer created CASSANDRA-17184:
--
Summary: Add += and -= syntax to ALTER TABLE WITH
Key: CASSANDRA-17184
URL: https://issues.apache.org/jira/browse/CASSANDRA-17184
Project: Cassandra
Issue Type: Improvement
Components: CQL/Syntax
Reporter: Benjamin Lerer
We have 2 types of table properties in CQL: simple ones (comment,
gc_grace_seconds, ...), which are basically of type text (even if, we
historically allow constants of any type) and complex ones (compaction,
caching...), which are basically map.
The only syntax that {{ALTER TABLE WITH}} supports is of setting a property,
and so for the later kind, we basically always have to provide the new full map
for the option. To take an example, say you have a table with compaction and
want to enable compaction logging you will have to provide the all map.
+Additional info for newcomers:+
In order to implement this change you will need to change the Parser.g ANTLR
file located in the src/antlr directory and the java classes corresponding to
the different alter statements located in the
{{org.apache.cassandra.cql3.statements.schema}} package.
The unit test for the CQL logic are located under
{{org.apache.cassandra.cql3.validation}}
In order to avoid that problem we can add support for the {{+=}} (and {{-=}}
ideally) syntax that already exists for maps otherwise, and support:
{{ALTER TABLE t WITH compaction+= \{ 'log_all' : 'true' \}}}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17048) Replace sequential sstable generation identifier with UUID v1
[ https://issues.apache.org/jira/browse/CASSANDRA-17048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17451169#comment-17451169 ] Benjamin Lerer edited comment on CASSANDRA-17048 at 12/3/21, 9:07 AM: -- One problem I see is with the current patch is that the existing tests will not check the use of the new identifier but the use of the old one. We also probably need to also check the transistion from the sequential one to the UUID one. was (Author: blerer): On problem, I see is with the current patch is that the existing tests will not check the use of the new identifier but the use of the old one. We also probably need to also check the transistion from the sequential one to the UUID one. > Replace sequential sstable generation identifier with UUID v1 > - > > Key: CASSANDRA-17048 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17048 > Project: Cassandra > Issue Type: Improvement > Components: Local/SSTable >Reporter: Jacek Lewandowski >Assignee: Jacek Lewandowski >Priority: Normal > Fix For: 4.1 > > Time Spent: 2h 50m > Remaining Estimate: 0h > > Replace the current sequential sstable generation identifier with ULID based. > ULID is better because we do not need to scan the existing files to pick the > starting number as well as we can generate globally unique identifiers. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17183) Using the user specified page size for internal paging in GROUP BY queries can slow down the query and create high traffic between nodes
Benjamin Lerer created CASSANDRA-17183: -- Summary: Using the user specified page size for internal paging in GROUP BY queries can slow down the query and create high traffic between nodes Key: CASSANDRA-17183 URL: https://issues.apache.org/jira/browse/CASSANDRA-17183 Project: Cassandra Issue Type: Bug Reporter: Benjamin Lerer When performing aggregation queries or GROUP BY queries Cassandra compute the aggregates on the coordinator node to ensure consistency and request the data by pages (numbers of rows). Today, Cassandra use as internal page size the page size requested by the user (the number of rows that should be returned to the user). By consequence, if the page size requested by the user is too small the number of request performed by the node will be much higher. For 1,000,000 rows, a consistency level of LOCAL_QUORUM and a page size of 5,000 the coordinator will contact 200 times the replicas. For a page size of 100 (CQLSH page size) the coordinator will contact 10,000 times the replicas. To avoid this problem we should have a minimum page size for the internal paging and the possibility for the operators to change its value. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14113) AssertionError while trying to upgrade 2.2.11 -> 3.11.1
[
https://issues.apache.org/jira/browse/CASSANDRA-14113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17452839#comment-17452839
]
Benjamin Lerer commented on CASSANDRA-14113:
Thanks for the patch [~knbk]. It looks good to me. I am just having some issues
with the upgrade tests. Due to some CI instabilities it is difficult to be sure
if the patch introduce a problem or not. I will look deeper into it but it
might take a bit of time as I got involved in to many things.
> AssertionError while trying to upgrade 2.2.11 -> 3.11.1
> ---
>
> Key: CASSANDRA-14113
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14113
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Core
> Environment: Tables have been created in 2.2.11 using thrift and have
> supercolumns
>Reporter: Guillaume Herail
>Assignee: Marten Kenbeek
>Priority: Normal
> Labels: supercolumns
> Attachments: 14113-3.0.txt, data.tar.gz
>
>
> We're trying to upgrade a test cluster from Cassandra 2.2.11 to Cassandra
> 3.11.1. The tables have been created using thrift and have supercolumns. When
> I try to run {{nodetool upgradesstables}} I get the following:
> {noformat}error: null
> -- StackTrace --
> java.lang.AssertionError
> at org.apache.cassandra.db.rows.BufferCell.(BufferCell.java:42)
> at
> org.apache.cassandra.db.LegacyLayout$CellGrouper.addCell(LegacyLayout.java:1242)
> at
> org.apache.cassandra.db.LegacyLayout$CellGrouper.addAtom(LegacyLayout.java:1185)
> at
> org.apache.cassandra.db.UnfilteredDeserializer$OldFormatDeserializer$UnfilteredIterator.readRow(UnfilteredDeserializer.java:498)
> at
> org.apache.cassandra.db.UnfilteredDeserializer$OldFormatDeserializer$UnfilteredIterator.hasNext(UnfilteredDeserializer.java:472)
> at
> org.apache.cassandra.db.UnfilteredDeserializer$OldFormatDeserializer.hasNext(UnfilteredDeserializer.java:306)
> at
> org.apache.cassandra.io.sstable.SSTableSimpleIterator$OldFormatIterator.computeNext(SSTableSimpleIterator.java:188)
> at
> org.apache.cassandra.io.sstable.SSTableSimpleIterator$OldFormatIterator.computeNext(SSTableSimpleIterator.java:140)
> at
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47)
> at
> org.apache.cassandra.io.sstable.SSTableIdentityIterator.hasNext(SSTableIdentityIterator.java:122)
> at
> org.apache.cassandra.db.rows.LazilyInitializedUnfilteredRowIterator.computeNext(LazilyInitializedUnfilteredRowIterator.java:100)
> at
> org.apache.cassandra.db.rows.LazilyInitializedUnfilteredRowIterator.computeNext(LazilyInitializedUnfilteredRowIterator.java:32)
> at
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47)
> at
> org.apache.cassandra.utils.MergeIterator$TrivialOneToOne.computeNext(MergeIterator.java:484)
> at
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47)
> at
> org.apache.cassandra.db.rows.UnfilteredRowIterators$UnfilteredRowMergeIterator.computeNext(UnfilteredRowIterators.java:499)
> at
> org.apache.cassandra.db.rows.UnfilteredRowIterators$UnfilteredRowMergeIterator.computeNext(UnfilteredRowIterators.java:359)
> at
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47)
> at org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:133)
> at
> org.apache.cassandra.db.transform.UnfilteredRows.isEmpty(UnfilteredRows.java:74)
> at
> org.apache.cassandra.db.partitions.PurgeFunction.applyToPartition(PurgeFunction.java:75)
> at
> org.apache.cassandra.db.partitions.PurgeFunction.applyToPartition(PurgeFunction.java:26)
> at
> org.apache.cassandra.db.transform.BasePartitions.hasNext(BasePartitions.java:96)
> at
> org.apache.cassandra.db.compaction.CompactionIterator.hasNext(CompactionIterator.java:233)
> at
> org.apache.cassandra.db.compaction.CompactionTask.runMayThrow(CompactionTask.java:196)
> at
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
> at
> org.apache.cassandra.db.compaction.CompactionTask.executeInternal(CompactionTask.java:85)
> at
> org.apache.cassandra.db.compaction.AbstractCompactionTask.execute(AbstractCompactionTask.java:61)
> at
> org.apache.cassandra.db.compaction.CompactionManager$5.execute(CompactionManager.java:428)
> at
> org.apache.cassandra.db.compaction.CompactionManager$2.call(CompactionManager.java:315)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolE
[jira] [Updated] (CASSANDRA-15511) Utilising BTree Improvements
[
https://issues.apache.org/jira/browse/CASSANDRA-15511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-15511:
---
Reviewers: Benjamin Lerer
> Utilising BTree Improvements
>
>
> Key: CASSANDRA-15511
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15511
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Other
>Reporter: Benedict Elliott Smith
>Assignee: Benedict Elliott Smith
>Priority: Normal
> Fix For: 4.0.x, 4.x
>
> Attachments: atomicbtreepartition.ods, atomicbtreepartition.xlsx.zip,
> perfsh.tar.gz
>
>
> This patch utilises CASSANDRA-15510 to improve throughput and reduce garbage
> produced by a number of common operations, by employing
> {{transformAndFilter}}, {{transform}} and {{FastBuilder}}
> * {{Row}}, {{Cell}} and {{ComplexColumnData}} cloning are implemented with
> {{BTree.transform}}, so no special builders are necessary;
> ** {{Rows.copy}} removed
> * {{Rows.merge}} implemented using {{BTree.update}} and a {{ColumnData}}
> reconciler
> ** Zero-allocations if result of merge is same as {{existing}}
> ** Fewer comparisons
> * {{ColumnData}} reconciler implemented in same manner
> ** {{Cells.reconcileComplex}} is retired
> ** {{ComplexColumnData}} reconciliation now
> *** Garbage-free if the merge has no effect
> *** Always fewer allocations
> *** Fewer comparisons
> * {{FastBuilder}} employed widely:
> ** {{ClusteringIndexNamesFilter}} deserialization
> ** {{Columns}} deserialization
> ** {{PartitionUpdate}} deserialization
> ** {{AbstractBTreePartition}} construction
> ** Misc others
> The upshot of this work when combined with the proposed patch for
> CASSANDRA-15367 has a dramatic impact on operations over collection types -
> under contention, as much as 100x improved throughput, and hundreds of
> megabytes of reduced allocations. For all operations, allocations under
> contention and no contention are significantly reduced and throughput
> improved.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15510) BTree: Improve Building, Inserting and Transforming
[
https://issues.apache.org/jira/browse/CASSANDRA-15510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-15510:
---
Reviewers: Benjamin Lerer
> BTree: Improve Building, Inserting and Transforming
> ---
>
> Key: CASSANDRA-15510
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15510
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Other
>Reporter: Benedict Elliott Smith
>Assignee: Benedict Elliott Smith
>Priority: Normal
> Fix For: 4.0.x, 4.x
>
>
> This work was originally undertaken as a follow-up to CASSANDRA-15367 to
> ensure performance is strictly improved, but it may no longer be needed for
> that purpose. It’s still hugely impactful, however. It remains to be
> decided where this should land.
> The current {{BTree}} implementation is suboptimal in a number of ways, with
> very little focus having been given to its performance besides its
> memory-occupancy. This patch aims to address that, specifically improving
> the performance and allocations involved in: building, transforming and
> inserting into a tree.
> To facilitate this work, the {{BTree}} definition is modified slightly, so
> that we can perform some simple arithmetic on tree sizes. Specifically,
> trees of depth n are defined to have a maximum capacity of {{branchFactor^n -
> 1}}, which translates into capping the number of leaf children at
> {{branchFactor-1}}, as opposed to {{branchFactor}}. Since {{branchFactor}}
> is a power of 2, this permits fast tree size arithmetic, enabling some of
> these changes.
> h2. Building
> The static build method has been modified to utilise dedicated
> {{buildPerfect}} methods that build either perfectly dense or perfectly
> sparse sub-trees. These perfect trees all share their {{sizeMap}} with each
> other, and can be built more efficiently than trees of arbitrary size. The
> specifics are described in detail in the comments, but this building block
> can be used to construct trees of any size, using at most one child at each
> level that is not either perfectly sparse or perfectly dense. Bulk methods
> are used where possible.
> For large trees this can produce up to 30x throughput improvement and 30%
> allocation reduction vs 3.0 (TBC, and to be tested vs 4.0).
> {{FastBuilder}} is introduced for building a tree in-order (or in reverse)
> without duplicate elements to resolve, without necessarily knowing the size
> upfront. This meets the needs of most use cases. Data is built directly
> into nodes, with up to one already-constructed node, and one partially
> constructed node, on each level, being mutated to share their contents in the
> event of insufficient data to populate the tree. These builders are
> thread-locally shared. These leads to minimal copying, the same sharing of
> {{sizeMap}} as above, zero wasted allocations, and results in minimal
> difference in performance between utilising the less-ergonomic static build
> and builder approach.
> For large trees this leads to ~4.5x throughput improvement, and 70% reduction
> in allocations vs a normal Builder. For small trees performance is
> comparable, but allocations similarly reduced.
> h2. Inserting
> It turns out that we only ever insert another tree into a tree, so we exploit
> this to implement an efficient union of two trees, operating on them directly
> via stacks in the transformer, instead of via a collection interface. A
> builder-like object is introduced that shares functionality with
> {{FastBuilder}}, and permits us to build the result of the union directly
> into the final nodes, reusing as much of the original trees as possible.
> Bulk methods are used where possible.
> The result is not _uniformly_ faster, but is _significantly_ faster on
> average: median _improvement_ of 1.4x (that is, 2.4x total throughput), mean
> improvement of 10x. Worst reduction is 30%, and it may be that we can
> isolate and alleviate that. Allocations are also reduced significantly, with
> a median of 30% and mean of 42% for the tested workloads. As the trees get
> larger the improvement drops, but remains uniformly lower.
> h2. Transforming
> Transformations garbage overhead is minimal, i.e. the main allocations are
> those necessary to represent the new tree. It is significantly faster and
> particularly more efficient when removing elements, utilising the shared
> functionality of the builder and transformer objects to define an efficient
> builder that reuses as much of the original tree as possible.
> We also introduce dedicated {{transform}} methods (that forbid returning
> {{null}}), and {{BiFunction}} transformations to permit efficient follow-ups.
--
This message was sent by Atlassian Jira
(
[jira] [Updated] (CASSANDRA-17181) schema.cql should have IF NOT EXISTS for CREATE TYPE
[
https://issues.apache.org/jira/browse/CASSANDRA-17181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-17181:
---
Labels: AdventCalendar2021 (was: )
> schema.cql should have IF NOT EXISTS for CREATE TYPE
>
>
> Key: CASSANDRA-17181
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17181
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Snapshots
>Reporter: Benjamin Lerer
>Priority: Normal
> Labels: AdventCalendar2021
> Fix For: 3.0.x, 3.11.x, 4.0.x
>
>
> When a schema.cql is created during a snapshot, {{CREATE TYPE}} statements
> are not created with {{IF NOT EXISTS}} as the {{CREATE TABLE}} statements.
> This can cause some issues when using those statements during restore.
> Additional Information for newcomers:
> In 3.0 and 3.11 the code use to generate the {{schema.cql}} file is in
> {{TableCQLHelper}} and the unit tests in {{TableCQLHelperTest}}.
> In 4.0 the bug does not exist anymore but the test {{SchemaCQLHelperTest}}
> does not test the correct behavior and the code could be simplified
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17181) schema.cql should have IF NOT EXISTS for CREATE TYPE
[
https://issues.apache.org/jira/browse/CASSANDRA-17181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-17181:
---
Bug Category: Parent values: Correctness(12982)
Complexity: Low Hanging Fruit
Discovered By: User Report
Fix Version/s: 3.0.x
3.11.x
4.0.x
Reviewers: Benjamin Lerer
Severity: Low
Assignee: (was: Benjamin Lerer)
Status: Open (was: Triage Needed)
> schema.cql should have IF NOT EXISTS for CREATE TYPE
>
>
> Key: CASSANDRA-17181
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17181
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Snapshots
>Reporter: Benjamin Lerer
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x
>
>
> When a schema.cql is created during a snapshot, {{CREATE TYPE}} statements
> are not created with {{IF NOT EXISTS}} as the {{CREATE TABLE}} statements.
> This can cause some issues when using those statements during restore.
> Additional Information for newcomers:
> In 3.0 and 3.11 the code use to generate the {{schema.cql}} file is in
> {{TableCQLHelper}} and the unit tests in {{TableCQLHelperTest}}.
> In 4.0 the bug does not exist anymore but the test {{SchemaCQLHelperTest}}
> does not test the correct behavior and the code could be simplified
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17181) schema.cql should have IF NOT EXISTS for CREATE TYPE
Benjamin Lerer created CASSANDRA-17181:
--
Summary: schema.cql should have IF NOT EXISTS for CREATE TYPE
Key: CASSANDRA-17181
URL: https://issues.apache.org/jira/browse/CASSANDRA-17181
Project: Cassandra
Issue Type: Bug
Components: Local/Snapshots
Reporter: Benjamin Lerer
Assignee: Benjamin Lerer
When a schema.cql is created during a snapshot, {{CREATE TYPE}} statements are
not created with {{IF NOT EXISTS}} as the {{CREATE TABLE}} statements. This can
cause some issues when using those statements during restore.
Additional Information for newcomers:
In 3.0 and 3.11 the code use to generate the {{schema.cql}} file is in
{{TableCQLHelper}} and the unit tests in {{TableCQLHelperTest}}.
In 4.0 the bug does not exist anymore but the test {{SchemaCQLHelperTest}} does
not test the correct behavior and the code could be simplified
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17048) Replace sequential sstable generation identifier with UUID v1
[ https://issues.apache.org/jira/browse/CASSANDRA-17048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17451169#comment-17451169 ] Benjamin Lerer commented on CASSANDRA-17048: On problem, I see is with the current patch is that the existing tests will not check the use of the new identifier but the use of the old one. We also probably need to also check the transistion from the sequential one to the UUID one. > Replace sequential sstable generation identifier with UUID v1 > - > > Key: CASSANDRA-17048 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17048 > Project: Cassandra > Issue Type: Improvement > Components: Local/SSTable >Reporter: Jacek Lewandowski >Assignee: Jacek Lewandowski >Priority: Normal > Fix For: 4.1 > > Time Spent: 2h 50m > Remaining Estimate: 0h > > Replace the current sequential sstable generation identifier with ULID based. > ULID is better because we do not need to scan the existing files to pick the > starting number as well as we can generate globally unique identifiers. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15254) Allow UPDATE on settings virtual table to change running configurations
[ https://issues.apache.org/jira/browse/CASSANDRA-15254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17450959#comment-17450959 ] Benjamin Lerer commented on CASSANDRA-15254: The current approach was exposing all Config fields in the virtual table even if those where deprecated as they were found through reflection. The idea was to not expose them in the virtual table. I kind of forget how [~e.dimitrova] patch is working. I would need to have a look at it. > Allow UPDATE on settings virtual table to change running configurations > --- > > Key: CASSANDRA-15254 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15254 > Project: Cassandra > Issue Type: New Feature > Components: Feature/Virtual Tables >Reporter: Chris Lohfink >Assignee: Benjamin Lerer >Priority: Normal > > Allow using UPDATE on the system_views.settings virtual table to update > configs at runtime for the equivalent of the dispersed JMX > attributes/operations. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17048) Replace sequential sstable generation identifier with ULID
[ https://issues.apache.org/jira/browse/CASSANDRA-17048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Lerer updated CASSANDRA-17048: --- Status: Review In Progress (was: Patch Available) > Replace sequential sstable generation identifier with ULID > -- > > Key: CASSANDRA-17048 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17048 > Project: Cassandra > Issue Type: Improvement > Components: Local/SSTable >Reporter: Jacek Lewandowski >Assignee: Jacek Lewandowski >Priority: Normal > Fix For: 4.1 > > Time Spent: 2h 10m > Remaining Estimate: 0h > > Replace the current sequential sstable generation identifier with ULID based. > ULID is better because we do not need to scan the existing files to pick the > starting number as well as we can generate globally unique identifiers. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16916) Add support for IF EXISTS and IF NOT EXISTS in ALTER statements
[
https://issues.apache.org/jira/browse/CASSANDRA-16916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-16916:
---
Reviewers: Benjamin Lerer
> Add support for IF EXISTS and IF NOT EXISTS in ALTER statements
> ---
>
> Key: CASSANDRA-16916
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16916
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Syntax
>Reporter: Benjamin Lerer
>Assignee: Jogesh Anand
>Priority: Normal
>
> It would make sense to add support for {{IF EXISTS}} and {{IF NOT EXISTS}} in
> the different {{ALTER}} statements.
> For example:
> * {{ALTER TABLE IF EXISTS myTable ...}}
> * {{ALTER TABLE myTable ADD IF NOT EXISTS ...}}
> * {{ALTER TABLE myTable DROP IF EXISTS ...}}
> * {{ALTER TYPE IF EXISTS myType ...}}
> * {{ALTER TYPE myType ADD IF NOT EXISTS ...}}
> +Additional info for newcomers:+
> In order to implement this change you will need to change the {{Parser.g}}
> ANTLR file located in the src/antlr directory and the java classes
> corresponding to the different alter statements located in the
> {{org.apache.cassandra.cql3.statements.schema}} package. You can look at the
> CreateTableStatement class to see how it was done there.
> The unit test for the CQL logic are located under
> {{org.apache.cassandra.cql3.validation}}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15254) Allow UPDATE on settings virtual table to change running configurations
[ https://issues.apache.org/jira/browse/CASSANDRA-15254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17447275#comment-17447275 ] Benjamin Lerer commented on CASSANDRA-15254: [~dcapwell] The patch I was working on took care of unifying the data logged by Config and exposed by the VirtualTable is was also taking into account sensible data through some new annotation and ignoring deprecated config settings. That approach was based on fields, which up to now where supposed to be always public (that used to be the convention for config fields). I did not realized that we intended to change that. May be we should also discuss this point in the current on going dev discussion. Once we have a clear vision of where the project wish to go with the configuration. I can come back to the patches and cook a new one keeping all the relevant bits and pieces from them :-) > Allow UPDATE on settings virtual table to change running configurations > --- > > Key: CASSANDRA-15254 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15254 > Project: Cassandra > Issue Type: New Feature > Components: Feature/Virtual Tables >Reporter: Chris Lohfink >Assignee: Benjamin Lerer >Priority: Normal > > Allow using UPDATE on the system_views.settings virtual table to update > configs at runtime for the equivalent of the dispersed JMX > attributes/operations. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15254) Allow UPDATE on settings virtual table to change running configurations
[ https://issues.apache.org/jira/browse/CASSANDRA-15254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Lerer updated CASSANDRA-15254: --- Change Category: Operability Complexity: Normal Status: Open (was: Triage Needed) > Allow UPDATE on settings virtual table to change running configurations > --- > > Key: CASSANDRA-15254 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15254 > Project: Cassandra > Issue Type: New Feature > Components: Feature/Virtual Tables >Reporter: Chris Lohfink >Assignee: Benjamin Lerer >Priority: Normal > > Allow using UPDATE on the system_views.settings virtual table to update > configs at runtime for the equivalent of the dispersed JMX > attributes/operations. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-15254) Allow UPDATE on settings virtual table to change running configurations
[ https://issues.apache.org/jira/browse/CASSANDRA-15254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Lerer reassigned CASSANDRA-15254: -- Assignee: Benjamin Lerer (was: Chris Lohfink) > Allow UPDATE on settings virtual table to change running configurations > --- > > Key: CASSANDRA-15254 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15254 > Project: Cassandra > Issue Type: New Feature > Components: Feature/Virtual Tables >Reporter: Chris Lohfink >Assignee: Benjamin Lerer >Priority: Normal > > Allow using UPDATE on the system_views.settings virtual table to update > configs at runtime for the equivalent of the dispersed JMX > attributes/operations. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17163) High CAS failures in MemtablePool.SubPool.tryAllocate
[
https://issues.apache.org/jira/browse/CASSANDRA-17163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17445951#comment-17445951
]
Benjamin Lerer edited comment on CASSANDRA-17163 at 11/18/21, 2:15 PM:
---
The only problem is that we need a fix for 3.11 and 4.0 and that
CASSANDRA-15511 is an improvement.
Now we should definetly get CASSANDRA-15511 in.
was (Author: blerer):
The only problem is that we need a fix for 3.11 and 4.0 and that
CASSANDRA-15511 is an improvement.
> High CAS failures in MemtablePool.SubPool.tryAllocate
> -
>
> Key: CASSANDRA-17163
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17163
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Local Write-Read Paths
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
>
> In a cluster using {{memtable_allocation_type: offheap_buffers}} which handle
> a high amount of writes we are seeing some high contentions on
> {{MemtablePool.SubPool.tryAllocate}}.
> {code}"MutationStage-561" #5457 daemon prio=5 os_prio=0
> tid=0x7f35dd3cfa50 nid=0x1407a runnable [0x7f2357fd5000]
>java.lang.Thread.State: RUNNABLE
> at
> org.apache.cassandra.utils.memory.MemtablePool$SubPool.tryAllocate(MemtablePool.java:159)
> at
> org.apache.cassandra.utils.memory.MemtableAllocator$SubAllocator.allocate(MemtableAllocator.java:175)
> at
> org.apache.cassandra.utils.memory.SlabAllocator.allocate(SlabAllocator.java:89)
> at
> org.apache.cassandra.utils.memory.ContextAllocator.allocate(ContextAllocator.java:57)
> at
> org.apache.cassandra.utils.memory.ContextAllocator.clone(ContextAllocator.java:47)
> at org.apache.cassandra.db.rows.BufferCell.copy(BufferCell.java:140)
> at
> org.apache.cassandra.utils.memory.AbstractAllocator$CloningBTreeRowBuilder.addCell(AbstractAllocator.java:89)
> at org.apache.cassandra.db.rows.Rows.copy(Rows.java:49)
> at
> org.apache.cassandra.db.partitions.AtomicBTreePartition$RowUpdater.apply(AtomicBTreePartition.java:370)
> at
> org.apache.cassandra.db.partitions.AtomicBTreePartition$RowUpdater.apply(AtomicBTreePartition.java:333)
> at org.apache.cassandra.utils.btree.BTree.buildLeaf(BTree.java:195)
> at org.apache.cassandra.utils.btree.BTree.buildInternal(BTree.java:208)
> at org.apache.cassandra.utils.btree.BTree.buildInternal(BTree.java:227)
> at org.apache.cassandra.utils.btree.BTree.buildInternal(BTree.java:254)
> at org.apache.cassandra.utils.btree.BTree.build(BTree.java:177)
> at org.apache.cassandra.utils.btree.BTree.update(BTree.java:283)
> at
> org.apache.cassandra.db.partitions.AtomicBTreePartition.addAllWithSizeDeltaInternal(AtomicBTreePartition.java:143)
> at
> org.apache.cassandra.db.partitions.AtomicBTreePartition.addAllWithSizeDelta(AtomicBTreePartition.java:184)
> at org.apache.cassandra.db.Memtable.put(Memtable.java:295)
> at
> org.apache.cassandra.db.ColumnFamilyStore.apply(ColumnFamilyStore.java:1335)
> at
> org.apache.cassandra.db.CassandraTableWriteHandler.write(CassandraTableWriteHandler.java:40)
> at org.apache.cassandra.db.Keyspace.applyInternal(Keyspace.java:661)
> at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:513)
> at org.apache.cassandra.db.Mutation.apply(Mutation.java:215)
> at org.apache.cassandra.db.Mutation.apply(Mutation.java:220)
> at org.apache.cassandra.db.Mutation.apply(Mutation.java:229)
> at
> org.apache.cassandra.service.StorageProxy$$Lambda$1019/640627333.run(Unknown
> Source)
> at
> org.apache.cassandra.service.StorageProxy$4.runMayThrow(StorageProxy.java:1544)
> at
> org.apache.cassandra.service.StorageProxy$LocalMutationRunnable$1.runMayThrow(StorageProxy.java:2314)
> at
> org.apache.cassandra.service.StorageProxy$HintRunnable.run(StorageProxy.java:2352)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:162)
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:134)
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:119)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:748)
>Locked ownable synchronizers:
> - None
> {code}
> This issue is similar to CASSANDRA-15922.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To uns
[jira] [Commented] (CASSANDRA-17163) High CAS failures in MemtablePool.SubPool.tryAllocate
[
https://issues.apache.org/jira/browse/CASSANDRA-17163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17445951#comment-17445951
]
Benjamin Lerer commented on CASSANDRA-17163:
The only problem is that we need a fix for 3.11 and 4.0 and that
CASSANDRA-15511 is an improvement.
> High CAS failures in MemtablePool.SubPool.tryAllocate
> -
>
> Key: CASSANDRA-17163
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17163
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Local Write-Read Paths
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
>
> In a cluster using {{memtable_allocation_type: offheap_buffers}} which handle
> a high amount of writes we are seeing some high contentions on
> {{MemtablePool.SubPool.tryAllocate}}.
> {code}"MutationStage-561" #5457 daemon prio=5 os_prio=0
> tid=0x7f35dd3cfa50 nid=0x1407a runnable [0x7f2357fd5000]
>java.lang.Thread.State: RUNNABLE
> at
> org.apache.cassandra.utils.memory.MemtablePool$SubPool.tryAllocate(MemtablePool.java:159)
> at
> org.apache.cassandra.utils.memory.MemtableAllocator$SubAllocator.allocate(MemtableAllocator.java:175)
> at
> org.apache.cassandra.utils.memory.SlabAllocator.allocate(SlabAllocator.java:89)
> at
> org.apache.cassandra.utils.memory.ContextAllocator.allocate(ContextAllocator.java:57)
> at
> org.apache.cassandra.utils.memory.ContextAllocator.clone(ContextAllocator.java:47)
> at org.apache.cassandra.db.rows.BufferCell.copy(BufferCell.java:140)
> at
> org.apache.cassandra.utils.memory.AbstractAllocator$CloningBTreeRowBuilder.addCell(AbstractAllocator.java:89)
> at org.apache.cassandra.db.rows.Rows.copy(Rows.java:49)
> at
> org.apache.cassandra.db.partitions.AtomicBTreePartition$RowUpdater.apply(AtomicBTreePartition.java:370)
> at
> org.apache.cassandra.db.partitions.AtomicBTreePartition$RowUpdater.apply(AtomicBTreePartition.java:333)
> at org.apache.cassandra.utils.btree.BTree.buildLeaf(BTree.java:195)
> at org.apache.cassandra.utils.btree.BTree.buildInternal(BTree.java:208)
> at org.apache.cassandra.utils.btree.BTree.buildInternal(BTree.java:227)
> at org.apache.cassandra.utils.btree.BTree.buildInternal(BTree.java:254)
> at org.apache.cassandra.utils.btree.BTree.build(BTree.java:177)
> at org.apache.cassandra.utils.btree.BTree.update(BTree.java:283)
> at
> org.apache.cassandra.db.partitions.AtomicBTreePartition.addAllWithSizeDeltaInternal(AtomicBTreePartition.java:143)
> at
> org.apache.cassandra.db.partitions.AtomicBTreePartition.addAllWithSizeDelta(AtomicBTreePartition.java:184)
> at org.apache.cassandra.db.Memtable.put(Memtable.java:295)
> at
> org.apache.cassandra.db.ColumnFamilyStore.apply(ColumnFamilyStore.java:1335)
> at
> org.apache.cassandra.db.CassandraTableWriteHandler.write(CassandraTableWriteHandler.java:40)
> at org.apache.cassandra.db.Keyspace.applyInternal(Keyspace.java:661)
> at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:513)
> at org.apache.cassandra.db.Mutation.apply(Mutation.java:215)
> at org.apache.cassandra.db.Mutation.apply(Mutation.java:220)
> at org.apache.cassandra.db.Mutation.apply(Mutation.java:229)
> at
> org.apache.cassandra.service.StorageProxy$$Lambda$1019/640627333.run(Unknown
> Source)
> at
> org.apache.cassandra.service.StorageProxy$4.runMayThrow(StorageProxy.java:1544)
> at
> org.apache.cassandra.service.StorageProxy$LocalMutationRunnable$1.runMayThrow(StorageProxy.java:2314)
> at
> org.apache.cassandra.service.StorageProxy$HintRunnable.run(StorageProxy.java:2352)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:162)
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:134)
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:119)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:748)
>Locked ownable synchronizers:
> - None
> {code}
> This issue is similar to CASSANDRA-15922.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17163) High CAS failures in MemtablePool.SubPool.tryAllocate
[
https://issues.apache.org/jira/browse/CASSANDRA-17163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-17163:
---
Bug Category: Parent values: Degradation(12984)
Complexity: Normal
Component/s: Legacy/Local Write-Read Paths
Discovered By: User Report
Severity: Normal
Status: Open (was: Triage Needed)
> High CAS failures in MemtablePool.SubPool.tryAllocate
> -
>
> Key: CASSANDRA-17163
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17163
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Local Write-Read Paths
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
>
> In a cluster using {{memtable_allocation_type: offheap_buffers}} which handle
> a high amount of writes we are seeing some high contentions on
> {{MemtablePool.SubPool.tryAllocate}}.
> {code}"MutationStage-561" #5457 daemon prio=5 os_prio=0
> tid=0x7f35dd3cfa50 nid=0x1407a runnable [0x7f2357fd5000]
>java.lang.Thread.State: RUNNABLE
> at
> org.apache.cassandra.utils.memory.MemtablePool$SubPool.tryAllocate(MemtablePool.java:159)
> at
> org.apache.cassandra.utils.memory.MemtableAllocator$SubAllocator.allocate(MemtableAllocator.java:175)
> at
> org.apache.cassandra.utils.memory.SlabAllocator.allocate(SlabAllocator.java:89)
> at
> org.apache.cassandra.utils.memory.ContextAllocator.allocate(ContextAllocator.java:57)
> at
> org.apache.cassandra.utils.memory.ContextAllocator.clone(ContextAllocator.java:47)
> at org.apache.cassandra.db.rows.BufferCell.copy(BufferCell.java:140)
> at
> org.apache.cassandra.utils.memory.AbstractAllocator$CloningBTreeRowBuilder.addCell(AbstractAllocator.java:89)
> at org.apache.cassandra.db.rows.Rows.copy(Rows.java:49)
> at
> org.apache.cassandra.db.partitions.AtomicBTreePartition$RowUpdater.apply(AtomicBTreePartition.java:370)
> at
> org.apache.cassandra.db.partitions.AtomicBTreePartition$RowUpdater.apply(AtomicBTreePartition.java:333)
> at org.apache.cassandra.utils.btree.BTree.buildLeaf(BTree.java:195)
> at org.apache.cassandra.utils.btree.BTree.buildInternal(BTree.java:208)
> at org.apache.cassandra.utils.btree.BTree.buildInternal(BTree.java:227)
> at org.apache.cassandra.utils.btree.BTree.buildInternal(BTree.java:254)
> at org.apache.cassandra.utils.btree.BTree.build(BTree.java:177)
> at org.apache.cassandra.utils.btree.BTree.update(BTree.java:283)
> at
> org.apache.cassandra.db.partitions.AtomicBTreePartition.addAllWithSizeDeltaInternal(AtomicBTreePartition.java:143)
> at
> org.apache.cassandra.db.partitions.AtomicBTreePartition.addAllWithSizeDelta(AtomicBTreePartition.java:184)
> at org.apache.cassandra.db.Memtable.put(Memtable.java:295)
> at
> org.apache.cassandra.db.ColumnFamilyStore.apply(ColumnFamilyStore.java:1335)
> at
> org.apache.cassandra.db.CassandraTableWriteHandler.write(CassandraTableWriteHandler.java:40)
> at org.apache.cassandra.db.Keyspace.applyInternal(Keyspace.java:661)
> at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:513)
> at org.apache.cassandra.db.Mutation.apply(Mutation.java:215)
> at org.apache.cassandra.db.Mutation.apply(Mutation.java:220)
> at org.apache.cassandra.db.Mutation.apply(Mutation.java:229)
> at
> org.apache.cassandra.service.StorageProxy$$Lambda$1019/640627333.run(Unknown
> Source)
> at
> org.apache.cassandra.service.StorageProxy$4.runMayThrow(StorageProxy.java:1544)
> at
> org.apache.cassandra.service.StorageProxy$LocalMutationRunnable$1.runMayThrow(StorageProxy.java:2314)
> at
> org.apache.cassandra.service.StorageProxy$HintRunnable.run(StorageProxy.java:2352)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:162)
> at
> org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:134)
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:119)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:748)
>Locked ownable synchronizers:
> - None
> {code}
> This issue is similar to CASSANDRA-15922.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17163) High CAS failures in MemtablePool.SubPool.tryAllocate
Benjamin Lerer created CASSANDRA-17163:
--
Summary: High CAS failures in MemtablePool.SubPool.tryAllocate
Key: CASSANDRA-17163
URL: https://issues.apache.org/jira/browse/CASSANDRA-17163
Project: Cassandra
Issue Type: Bug
Reporter: Benjamin Lerer
Assignee: Benjamin Lerer
In a cluster using {{memtable_allocation_type: offheap_buffers}} which handle a
high amount of writes we are seeing some high contentions on
{{MemtablePool.SubPool.tryAllocate}}.
{code}"MutationStage-561" #5457 daemon prio=5 os_prio=0 tid=0x7f35dd3cfa50
nid=0x1407a runnable [0x7f2357fd5000]
java.lang.Thread.State: RUNNABLE
at
org.apache.cassandra.utils.memory.MemtablePool$SubPool.tryAllocate(MemtablePool.java:159)
at
org.apache.cassandra.utils.memory.MemtableAllocator$SubAllocator.allocate(MemtableAllocator.java:175)
at
org.apache.cassandra.utils.memory.SlabAllocator.allocate(SlabAllocator.java:89)
at
org.apache.cassandra.utils.memory.ContextAllocator.allocate(ContextAllocator.java:57)
at
org.apache.cassandra.utils.memory.ContextAllocator.clone(ContextAllocator.java:47)
at org.apache.cassandra.db.rows.BufferCell.copy(BufferCell.java:140)
at
org.apache.cassandra.utils.memory.AbstractAllocator$CloningBTreeRowBuilder.addCell(AbstractAllocator.java:89)
at org.apache.cassandra.db.rows.Rows.copy(Rows.java:49)
at
org.apache.cassandra.db.partitions.AtomicBTreePartition$RowUpdater.apply(AtomicBTreePartition.java:370)
at
org.apache.cassandra.db.partitions.AtomicBTreePartition$RowUpdater.apply(AtomicBTreePartition.java:333)
at org.apache.cassandra.utils.btree.BTree.buildLeaf(BTree.java:195)
at org.apache.cassandra.utils.btree.BTree.buildInternal(BTree.java:208)
at org.apache.cassandra.utils.btree.BTree.buildInternal(BTree.java:227)
at org.apache.cassandra.utils.btree.BTree.buildInternal(BTree.java:254)
at org.apache.cassandra.utils.btree.BTree.build(BTree.java:177)
at org.apache.cassandra.utils.btree.BTree.update(BTree.java:283)
at
org.apache.cassandra.db.partitions.AtomicBTreePartition.addAllWithSizeDeltaInternal(AtomicBTreePartition.java:143)
at
org.apache.cassandra.db.partitions.AtomicBTreePartition.addAllWithSizeDelta(AtomicBTreePartition.java:184)
at org.apache.cassandra.db.Memtable.put(Memtable.java:295)
at
org.apache.cassandra.db.ColumnFamilyStore.apply(ColumnFamilyStore.java:1335)
at
org.apache.cassandra.db.CassandraTableWriteHandler.write(CassandraTableWriteHandler.java:40)
at org.apache.cassandra.db.Keyspace.applyInternal(Keyspace.java:661)
at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:513)
at org.apache.cassandra.db.Mutation.apply(Mutation.java:215)
at org.apache.cassandra.db.Mutation.apply(Mutation.java:220)
at org.apache.cassandra.db.Mutation.apply(Mutation.java:229)
at
org.apache.cassandra.service.StorageProxy$$Lambda$1019/640627333.run(Unknown
Source)
at
org.apache.cassandra.service.StorageProxy$4.runMayThrow(StorageProxy.java:1544)
at
org.apache.cassandra.service.StorageProxy$LocalMutationRunnable$1.runMayThrow(StorageProxy.java:2314)
at
org.apache.cassandra.service.StorageProxy$HintRunnable.run(StorageProxy.java:2352)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at
org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:162)
at
org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$LocalSessionFutureTask.run(AbstractLocalAwareExecutorService.java:134)
at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:119)
at
io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
at java.lang.Thread.run(Thread.java:748)
Locked ownable synchronizers:
- None
{code}
This issue is similar to CASSANDRA-15922.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17157) WEBSITE - November 2021 blog post titled Inside Cassandra: an interview with Marcel Birkner at Instana
[ https://issues.apache.org/jira/browse/CASSANDRA-17157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Lerer updated CASSANDRA-17157: --- Source Control Link: https://github.com/apache/cassandra-website/commit/7324a6f2623dd39d140bf9ad6394bb9208cfb1d6 Resolution: Fixed Status: Resolved (was: Ready to Commit) > WEBSITE - November 2021 blog post titled Inside Cassandra: an interview with > Marcel Birkner at Instana > -- > > Key: CASSANDRA-17157 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17157 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Diogenese Topper >Assignee: Erick Ramirez >Priority: Urgent > Labels: pull-request-available, pull-requests-available > Fix For: 4.0.2, 4.1 > > Attachments: c17157-01-blog-index.png, c17157-02-blog-post.png > > > This ticket is to capture the work associated with publishing the November > 2021 blog post for "Inside Cassandra: an interview with Marcel Birkner at > Instana." > If this blog cannot be published by the *November 17 publish date*, please be > sure to *correct the date before going live*. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16916) Add support for IF EXISTS and IF NOT EXISTS in ALTER statements
[
https://issues.apache.org/jira/browse/CASSANDRA-16916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17444500#comment-17444500
]
Benjamin Lerer commented on CASSANDRA-16916:
Thanks [~djanand]. We will look into it shortly :-)
You should have received an invitation to the Slack channel.
> Add support for IF EXISTS and IF NOT EXISTS in ALTER statements
> ---
>
> Key: CASSANDRA-16916
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16916
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Syntax
>Reporter: Benjamin Lerer
>Assignee: Jogesh Anand
>Priority: Normal
>
> It would make sense to add support for {{IF EXISTS}} and {{IF NOT EXISTS}} in
> the different {{ALTER}} statements.
> For example:
> * {{ALTER TABLE IF EXISTS myTable ...}}
> * {{ALTER TABLE myTable ADD IF NOT EXISTS ...}}
> * {{ALTER TABLE myTable DROP IF EXISTS ...}}
> * {{ALTER TYPE IF EXISTS myType ...}}
> * {{ALTER TYPE myType ADD IF NOT EXISTS ...}}
> +Additional info for newcomers:+
> In order to implement this change you will need to change the {{Parser.g}}
> ANTLR file located in the src/antlr directory and the java classes
> corresponding to the different alter statements located in the
> {{org.apache.cassandra.cql3.statements.schema}} package. You can look at the
> CreateTableStatement class to see how it was done there.
> The unit test for the CQL logic are located under
> {{org.apache.cassandra.cql3.validation}}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-17137) utests_system_keyspace_directory - more than 500 tests failing on trunk
[
https://issues.apache.org/jira/browse/CASSANDRA-17137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer reassigned CASSANDRA-17137:
--
Assignee: Benjamin Lerer
> utests_system_keyspace_directory - more than 500 tests failing on trunk
> ---
>
> Key: CASSANDRA-17137
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17137
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 4.x
>
>
> I have more than 500 tests failing on trunk [with the
> new|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1194/workflows/5fb2b193-d99a-4168-b10d-f7a3a05a3abf/jobs/7136]
> and [with the old
> image|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1189/workflows/416dcd5e-720e-4eca-b3d5-61767906457b/jobs/6984/tests#failed-test-1]
> - please check under {_}utests_system_keyspace_directory{_}.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16914) Implement Virtual Tables for Auth Caches
[
https://issues.apache.org/jira/browse/CASSANDRA-16914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17441204#comment-17441204
]
Benjamin Lerer commented on CASSANDRA-16914:
+1 on my side.
> Implement Virtual Tables for Auth Caches
>
>
> Key: CASSANDRA-16914
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16914
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Authorization, Feature/Virtual Tables
>Reporter: Aleksei Zotov
>Assignee: Aleksei Zotov
>Priority: Low
> Fix For: 4.x
>
> Time Spent: 2h 40m
> Remaining Estimate: 0h
>
> {{NodeTool}} commands for Auth Caches invalidation were implemented as a part
> of CASSANDRA-16404 ticket. While discussing that ticket it was agreed that
> there is a need to develop the same kind of functionality through Vitrual
> Tables. Unfortunately, VT did not have {{TRUNCATE}} and {{DELETE}} support.
> And CASSANDRA-16806 was created for that reason. Once it is completed,
> further work can be started.
> The goal of this ticket is to create VTs for the following caches:
> * {{CredentialsCache}}
> * {{JmxPermissionsCache}}
> * {{NetworkPermissionsCache}}
> * {{PermissionsCache}}
> * {{RolesCache}}
> The VTs should support reading from and modification of the in the Auth
> Caches.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16914) Implement Virtual Tables for Auth Caches
[
https://issues.apache.org/jira/browse/CASSANDRA-16914?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-16914:
---
Reviewers: Benjamin Lerer, Sam Tunnicliffe (was: Benjamin Lerer, beobal)
> Implement Virtual Tables for Auth Caches
>
>
> Key: CASSANDRA-16914
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16914
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Authorization, Feature/Virtual Tables
>Reporter: Aleksei Zotov
>Assignee: Aleksei Zotov
>Priority: Low
> Fix For: 4.x
>
> Time Spent: 2h 40m
> Remaining Estimate: 0h
>
> {{NodeTool}} commands for Auth Caches invalidation were implemented as a part
> of CASSANDRA-16404 ticket. While discussing that ticket it was agreed that
> there is a need to develop the same kind of functionality through Vitrual
> Tables. Unfortunately, VT did not have {{TRUNCATE}} and {{DELETE}} support.
> And CASSANDRA-16806 was created for that reason. Once it is completed,
> further work can be started.
> The goal of this ticket is to create VTs for the following caches:
> * {{CredentialsCache}}
> * {{JmxPermissionsCache}}
> * {{NetworkPermissionsCache}}
> * {{PermissionsCache}}
> * {{RolesCache}}
> The VTs should support reading from and modification of the in the Auth
> Caches.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16914) Implement Virtual Tables for Auth Caches
[
https://issues.apache.org/jira/browse/CASSANDRA-16914?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-16914:
---
Status: Review In Progress (was: Patch Available)
> Implement Virtual Tables for Auth Caches
>
>
> Key: CASSANDRA-16914
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16914
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Authorization, Feature/Virtual Tables
>Reporter: Aleksei Zotov
>Assignee: Aleksei Zotov
>Priority: Low
> Fix For: 4.x
>
> Time Spent: 2h 40m
> Remaining Estimate: 0h
>
> {{NodeTool}} commands for Auth Caches invalidation were implemented as a part
> of CASSANDRA-16404 ticket. While discussing that ticket it was agreed that
> there is a need to develop the same kind of functionality through Vitrual
> Tables. Unfortunately, VT did not have {{TRUNCATE}} and {{DELETE}} support.
> And CASSANDRA-16806 was created for that reason. Once it is completed,
> further work can be started.
> The goal of this ticket is to create VTs for the following caches:
> * {{CredentialsCache}}
> * {{JmxPermissionsCache}}
> * {{NetworkPermissionsCache}}
> * {{PermissionsCache}}
> * {{RolesCache}}
> The VTs should support reading from and modification of the in the Auth
> Caches.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16914) Implement Virtual Tables for Auth Caches
[
https://issues.apache.org/jira/browse/CASSANDRA-16914?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-16914:
---
Reviewers: Benjamin Lerer, beobal (was: Benjamin Lerer)
> Implement Virtual Tables for Auth Caches
>
>
> Key: CASSANDRA-16914
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16914
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Authorization, Feature/Virtual Tables
>Reporter: Aleksei Zotov
>Assignee: Aleksei Zotov
>Priority: Low
> Fix For: 4.x
>
> Time Spent: 2h 40m
> Remaining Estimate: 0h
>
> {{NodeTool}} commands for Auth Caches invalidation were implemented as a part
> of CASSANDRA-16404 ticket. While discussing that ticket it was agreed that
> there is a need to develop the same kind of functionality through Vitrual
> Tables. Unfortunately, VT did not have {{TRUNCATE}} and {{DELETE}} support.
> And CASSANDRA-16806 was created for that reason. Once it is completed,
> further work can be started.
> The goal of this ticket is to create VTs for the following caches:
> * {{CredentialsCache}}
> * {{JmxPermissionsCache}}
> * {{NetworkPermissionsCache}}
> * {{PermissionsCache}}
> * {{RolesCache}}
> The VTs should support reading from and modification of the in the Auth
> Caches.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14113) AssertionError while trying to upgrade 2.2.11 -> 3.11.1
[
https://issues.apache.org/jira/browse/CASSANDRA-14113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-14113:
---
Reviewers: Benjamin Lerer, Benjamin Lerer (was: Benjamin Lerer)
Benjamin Lerer, Benjamin Lerer (was: Benjamin Lerer)
Status: Review In Progress (was: Patch Available)
> AssertionError while trying to upgrade 2.2.11 -> 3.11.1
> ---
>
> Key: CASSANDRA-14113
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14113
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Core
> Environment: Tables have been created in 2.2.11 using thrift and have
> supercolumns
>Reporter: Guillaume Herail
>Assignee: Marten Kenbeek
>Priority: Normal
> Labels: supercolumns
> Attachments: 14113-3.0.txt, data.tar.gz
>
>
> We're trying to upgrade a test cluster from Cassandra 2.2.11 to Cassandra
> 3.11.1. The tables have been created using thrift and have supercolumns. When
> I try to run {{nodetool upgradesstables}} I get the following:
> {noformat}error: null
> -- StackTrace --
> java.lang.AssertionError
> at org.apache.cassandra.db.rows.BufferCell.(BufferCell.java:42)
> at
> org.apache.cassandra.db.LegacyLayout$CellGrouper.addCell(LegacyLayout.java:1242)
> at
> org.apache.cassandra.db.LegacyLayout$CellGrouper.addAtom(LegacyLayout.java:1185)
> at
> org.apache.cassandra.db.UnfilteredDeserializer$OldFormatDeserializer$UnfilteredIterator.readRow(UnfilteredDeserializer.java:498)
> at
> org.apache.cassandra.db.UnfilteredDeserializer$OldFormatDeserializer$UnfilteredIterator.hasNext(UnfilteredDeserializer.java:472)
> at
> org.apache.cassandra.db.UnfilteredDeserializer$OldFormatDeserializer.hasNext(UnfilteredDeserializer.java:306)
> at
> org.apache.cassandra.io.sstable.SSTableSimpleIterator$OldFormatIterator.computeNext(SSTableSimpleIterator.java:188)
> at
> org.apache.cassandra.io.sstable.SSTableSimpleIterator$OldFormatIterator.computeNext(SSTableSimpleIterator.java:140)
> at
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47)
> at
> org.apache.cassandra.io.sstable.SSTableIdentityIterator.hasNext(SSTableIdentityIterator.java:122)
> at
> org.apache.cassandra.db.rows.LazilyInitializedUnfilteredRowIterator.computeNext(LazilyInitializedUnfilteredRowIterator.java:100)
> at
> org.apache.cassandra.db.rows.LazilyInitializedUnfilteredRowIterator.computeNext(LazilyInitializedUnfilteredRowIterator.java:32)
> at
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47)
> at
> org.apache.cassandra.utils.MergeIterator$TrivialOneToOne.computeNext(MergeIterator.java:484)
> at
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47)
> at
> org.apache.cassandra.db.rows.UnfilteredRowIterators$UnfilteredRowMergeIterator.computeNext(UnfilteredRowIterators.java:499)
> at
> org.apache.cassandra.db.rows.UnfilteredRowIterators$UnfilteredRowMergeIterator.computeNext(UnfilteredRowIterators.java:359)
> at
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47)
> at org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:133)
> at
> org.apache.cassandra.db.transform.UnfilteredRows.isEmpty(UnfilteredRows.java:74)
> at
> org.apache.cassandra.db.partitions.PurgeFunction.applyToPartition(PurgeFunction.java:75)
> at
> org.apache.cassandra.db.partitions.PurgeFunction.applyToPartition(PurgeFunction.java:26)
> at
> org.apache.cassandra.db.transform.BasePartitions.hasNext(BasePartitions.java:96)
> at
> org.apache.cassandra.db.compaction.CompactionIterator.hasNext(CompactionIterator.java:233)
> at
> org.apache.cassandra.db.compaction.CompactionTask.runMayThrow(CompactionTask.java:196)
> at
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
> at
> org.apache.cassandra.db.compaction.CompactionTask.executeInternal(CompactionTask.java:85)
> at
> org.apache.cassandra.db.compaction.AbstractCompactionTask.execute(AbstractCompactionTask.java:61)
> at
> org.apache.cassandra.db.compaction.CompactionManager$5.execute(CompactionManager.java:428)
> at
> org.apache.cassandra.db.compaction.CompactionManager$2.call(CompactionManager.java:315)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:81)
> at java.lan
[jira] [Commented] (CASSANDRA-15975) SEP.shutdownAndWait does not wait for termination and SEPExecutor.awaitTermination may hang
[ https://issues.apache.org/jira/browse/CASSANDRA-15975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17441163#comment-17441163 ] Benjamin Lerer commented on CASSANDRA-15975: Gentle ping [~jmeredithco] > SEP.shutdownAndWait does not wait for termination and > SEPExecutor.awaitTermination may hang > --- > > Key: CASSANDRA-15975 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15975 > Project: Cassandra > Issue Type: Bug > Components: Local/Other >Reporter: Jon Meredith >Assignee: Jon Meredith >Priority: Normal > > SharedExecutorPool.shutdownAndWait calls shutdownNow on the executors it > owns, which has the side effect of removing the executor from the list, then > uses the same emptied list to try and wait for them to complete shutting > down, which completes immediately. > > Once fixed by copying the list in SEP.shutdownAndWait, the SEPExecutorTest > suite fails with a timeout due to a startup race in SEPWorker. > > If a SEPExecutor is shutdown immediately after maybeSchedule creates a new > SEPWorker, > but before it is able to execute the first task then it exits immediately on > entering the work loop with a work and task permit reserved for it, which > invalidates the work/task permit accounting and prevents calling the shutdown > SimpleCondition.signalAll when the last SEPWorker exits. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17029) Add unix time conversion functions
[
https://issues.apache.org/jira/browse/CASSANDRA-17029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17441162#comment-17441162
]
Benjamin Lerer commented on CASSANDRA-17029:
Thanks a lot for the patch [~subkanthi]
> Add unix time conversion functions
> --
>
> Key: CASSANDRA-17029
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17029
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Syntax
>Reporter: Benjamin Lerer
>Assignee: Kanthi Subramanian
>Priority: Normal
> Fix For: 4.1
>
>
> It will be useful to have some functions to conver unix time values into C*
> native types, like:
> * {{toDate(bigint)}}
> * {{toTimestamp(bigint)}}
> * {{mintimeuuid(bigint)}}
> * {{maxtimeuuid(bigint)}}
> +Additional info for newcomers:+
> Those new functions need to be added to
> {{org.apache.cassandra.cql3.functions.TimeFcts}} and some unit tests need to
> be added to {{org.apache.cassandra.cql3.functions..TimeFctsTest}}. The other
> functions in {{TimeFcts}} provide some good example of how to create new
> functions.
> As it is a new functionality they need to be mentioned in the {{NEWS.txt}}
> file.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17029) Add unix time conversion functions
[
https://issues.apache.org/jira/browse/CASSANDRA-17029?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-17029:
---
Fix Version/s: 4.1
Source Control Link:
https://github.com/apache/cassandra/commit/8ddcd43b0cfcebfda882a238532d00905fe85eb8
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
Committed into trunk at 8ddcd43b0cfcebfda882a238532d00905fe85eb8
> Add unix time conversion functions
> --
>
> Key: CASSANDRA-17029
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17029
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Syntax
>Reporter: Benjamin Lerer
>Assignee: Kanthi Subramanian
>Priority: Normal
> Fix For: 4.1
>
>
> It will be useful to have some functions to conver unix time values into C*
> native types, like:
> * {{toDate(bigint)}}
> * {{toTimestamp(bigint)}}
> * {{mintimeuuid(bigint)}}
> * {{maxtimeuuid(bigint)}}
> +Additional info for newcomers:+
> Those new functions need to be added to
> {{org.apache.cassandra.cql3.functions.TimeFcts}} and some unit tests need to
> be added to {{org.apache.cassandra.cql3.functions..TimeFctsTest}}. The other
> functions in {{TimeFcts}} provide some good example of how to create new
> functions.
> As it is a new functionality they need to be mentioned in the {{NEWS.txt}}
> file.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17048) Replace sequential sstable generation identifier with ULID
[ https://issues.apache.org/jira/browse/CASSANDRA-17048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Lerer updated CASSANDRA-17048: --- Reviewers: Benjamin Lerer > Replace sequential sstable generation identifier with ULID > -- > > Key: CASSANDRA-17048 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17048 > Project: Cassandra > Issue Type: Improvement > Components: Local/SSTable >Reporter: Jacek Lewandowski >Assignee: Jacek Lewandowski >Priority: Normal > Fix For: 4.1 > > Time Spent: 2h 10m > Remaining Estimate: 0h > > Replace the current sequential sstable generation identifier with ULID based. > ULID is better because we do not need to scan the existing files to pick the > starting number as well as we can generate globally unique identifiers. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17120) Flaky test - org.apache.cassandra.serializers.TimestampSerializerTest
[
https://issues.apache.org/jira/browse/CASSANDRA-17120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17440510#comment-17440510
]
Benjamin Lerer edited comment on CASSANDRA-17120 at 11/8/21, 2:38 PM:
--
The issue is that the comparison is done between the output of
{{System.currentTimeMillis}} and the output of the {{Clock}} used by the
function. The test need to use the output of the {{Clock}} for computing the
expected value.
was (Author: blerer):
The issue is that the comparison is done between the output of
{{System.currentTimeMillis}} and the output of the {{Clock}} used but the
function. The test need to use the output of the {{Clock}} for computing the
expected value.
> Flaky test - org.apache.cassandra.serializers.TimestampSerializerTest
> -
>
> Key: CASSANDRA-17120
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17120
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Brandon Williams
>Priority: Normal
> Fix For: 4.x
>
>
> As seen here:
> https://app.circleci.com/pipelines/github/blerer/cassandra/239/workflows/32b4bc10-685a-4719-ac6c-950e76cd9533/jobs/2144
> {noformat}
> junit.framework.AssertionFailedError: 'now' timestamp not within expected
> tolerance.
> at
> org.apache.cassandra.serializers.TimestampSerializerTest.testNow(TimestampSerializerTest.java:227)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17120) Flaky test - org.apache.cassandra.serializers.TimestampSerializerTest
[
https://issues.apache.org/jira/browse/CASSANDRA-17120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17440510#comment-17440510
]
Benjamin Lerer commented on CASSANDRA-17120:
The issue is that the comparison is done between the output of
{{System.currentTimeMillis}} and the output of the {{Clock}} used but the
function. The test need to use the output of the {{Clock}} for computing the
expected value.
> Flaky test - org.apache.cassandra.serializers.TimestampSerializerTest
> -
>
> Key: CASSANDRA-17120
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17120
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Brandon Williams
>Priority: Normal
> Fix For: 4.x
>
>
> As seen here:
> https://app.circleci.com/pipelines/github/blerer/cassandra/239/workflows/32b4bc10-685a-4719-ac6c-950e76cd9533/jobs/2144
> {noformat}
> junit.framework.AssertionFailedError: 'now' timestamp not within expected
> tolerance.
> at
> org.apache.cassandra.serializers.TimestampSerializerTest.testNow(TimestampSerializerTest.java:227)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17029) Add unix time conversion functions
[
https://issues.apache.org/jira/browse/CASSANDRA-17029?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-17029:
---
Status: Needs Committer (was: Review In Progress)
> Add unix time conversion functions
> --
>
> Key: CASSANDRA-17029
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17029
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Syntax
>Reporter: Benjamin Lerer
>Assignee: Kanthi Subramanian
>Priority: Normal
>
> It will be useful to have some functions to conver unix time values into C*
> native types, like:
> * {{toDate(bigint)}}
> * {{toTimestamp(bigint)}}
> * {{mintimeuuid(bigint)}}
> * {{maxtimeuuid(bigint)}}
> +Additional info for newcomers:+
> Those new functions need to be added to
> {{org.apache.cassandra.cql3.functions.TimeFcts}} and some unit tests need to
> be added to {{org.apache.cassandra.cql3.functions..TimeFctsTest}}. The other
> functions in {{TimeFcts}} provide some good example of how to create new
> functions.
> As it is a new functionality they need to be mentioned in the {{NEWS.txt}}
> file.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17029) Add unix time conversion functions
[
https://issues.apache.org/jira/browse/CASSANDRA-17029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17438752#comment-17438752
]
Benjamin Lerer commented on CASSANDRA-17029:
The patch looks good to me. CI results are
[here|https://app.circleci.com/pipelines/github/blerer/cassandra/239/workflows/32b4bc10-685a-4719-ac6c-950e76cd9533].
Failing tests are unrelated to the change.
> Add unix time conversion functions
> --
>
> Key: CASSANDRA-17029
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17029
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Syntax
>Reporter: Benjamin Lerer
>Assignee: Kanthi Subramanian
>Priority: Normal
>
> It will be useful to have some functions to conver unix time values into C*
> native types, like:
> * {{toDate(bigint)}}
> * {{toTimestamp(bigint)}}
> * {{mintimeuuid(bigint)}}
> * {{maxtimeuuid(bigint)}}
> +Additional info for newcomers:+
> Those new functions need to be added to
> {{org.apache.cassandra.cql3.functions.TimeFcts}} and some unit tests need to
> be added to {{org.apache.cassandra.cql3.functions..TimeFctsTest}}. The other
> functions in {{TimeFcts}} provide some good example of how to create new
> functions.
> As it is a new functionality they need to be mentioned in the {{NEWS.txt}}
> file.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14113) AssertionError while trying to upgrade 2.2.11 -> 3.11.1
[
https://issues.apache.org/jira/browse/CASSANDRA-14113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-14113:
---
Reviewers: Benjamin Lerer
> AssertionError while trying to upgrade 2.2.11 -> 3.11.1
> ---
>
> Key: CASSANDRA-14113
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14113
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Core
> Environment: Tables have been created in 2.2.11 using thrift and have
> supercolumns
>Reporter: Guillaume Herail
>Assignee: Marten Kenbeek
>Priority: Normal
> Labels: supercolumns
> Attachments: 14113-3.0.txt, data.tar.gz
>
>
> We're trying to upgrade a test cluster from Cassandra 2.2.11 to Cassandra
> 3.11.1. The tables have been created using thrift and have supercolumns. When
> I try to run {{nodetool upgradesstables}} I get the following:
> {noformat}error: null
> -- StackTrace --
> java.lang.AssertionError
> at org.apache.cassandra.db.rows.BufferCell.(BufferCell.java:42)
> at
> org.apache.cassandra.db.LegacyLayout$CellGrouper.addCell(LegacyLayout.java:1242)
> at
> org.apache.cassandra.db.LegacyLayout$CellGrouper.addAtom(LegacyLayout.java:1185)
> at
> org.apache.cassandra.db.UnfilteredDeserializer$OldFormatDeserializer$UnfilteredIterator.readRow(UnfilteredDeserializer.java:498)
> at
> org.apache.cassandra.db.UnfilteredDeserializer$OldFormatDeserializer$UnfilteredIterator.hasNext(UnfilteredDeserializer.java:472)
> at
> org.apache.cassandra.db.UnfilteredDeserializer$OldFormatDeserializer.hasNext(UnfilteredDeserializer.java:306)
> at
> org.apache.cassandra.io.sstable.SSTableSimpleIterator$OldFormatIterator.computeNext(SSTableSimpleIterator.java:188)
> at
> org.apache.cassandra.io.sstable.SSTableSimpleIterator$OldFormatIterator.computeNext(SSTableSimpleIterator.java:140)
> at
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47)
> at
> org.apache.cassandra.io.sstable.SSTableIdentityIterator.hasNext(SSTableIdentityIterator.java:122)
> at
> org.apache.cassandra.db.rows.LazilyInitializedUnfilteredRowIterator.computeNext(LazilyInitializedUnfilteredRowIterator.java:100)
> at
> org.apache.cassandra.db.rows.LazilyInitializedUnfilteredRowIterator.computeNext(LazilyInitializedUnfilteredRowIterator.java:32)
> at
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47)
> at
> org.apache.cassandra.utils.MergeIterator$TrivialOneToOne.computeNext(MergeIterator.java:484)
> at
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47)
> at
> org.apache.cassandra.db.rows.UnfilteredRowIterators$UnfilteredRowMergeIterator.computeNext(UnfilteredRowIterators.java:499)
> at
> org.apache.cassandra.db.rows.UnfilteredRowIterators$UnfilteredRowMergeIterator.computeNext(UnfilteredRowIterators.java:359)
> at
> org.apache.cassandra.utils.AbstractIterator.hasNext(AbstractIterator.java:47)
> at org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:133)
> at
> org.apache.cassandra.db.transform.UnfilteredRows.isEmpty(UnfilteredRows.java:74)
> at
> org.apache.cassandra.db.partitions.PurgeFunction.applyToPartition(PurgeFunction.java:75)
> at
> org.apache.cassandra.db.partitions.PurgeFunction.applyToPartition(PurgeFunction.java:26)
> at
> org.apache.cassandra.db.transform.BasePartitions.hasNext(BasePartitions.java:96)
> at
> org.apache.cassandra.db.compaction.CompactionIterator.hasNext(CompactionIterator.java:233)
> at
> org.apache.cassandra.db.compaction.CompactionTask.runMayThrow(CompactionTask.java:196)
> at
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
> at
> org.apache.cassandra.db.compaction.CompactionTask.executeInternal(CompactionTask.java:85)
> at
> org.apache.cassandra.db.compaction.AbstractCompactionTask.execute(AbstractCompactionTask.java:61)
> at
> org.apache.cassandra.db.compaction.CompactionManager$5.execute(CompactionManager.java:428)
> at
> org.apache.cassandra.db.compaction.CompactionManager$2.call(CompactionManager.java:315)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:81)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> We also tried to upgrade to 3.0.15 instead and had a different error:
> {noformat}
> ERROR 11:00:40 Exception in thread T
[jira] [Updated] (CASSANDRA-16801) PasswordObfuscator should not assume PASSWORD is the last item in the WITH clause
[
https://issues.apache.org/jira/browse/CASSANDRA-16801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-16801:
---
Status: Review In Progress (was: Needs Committer)
> PasswordObfuscator should not assume PASSWORD is the last item in the WITH
> clause
> -
>
> Key: CASSANDRA-16801
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16801
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/auditlogging
>Reporter: Caleb Rackliffe
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0.x, 4.x
>
>
> CASSANDRA-16669 introduced support for obfuscating passwords for audit log
> statements, but there are a few cases where the obfuscation logic can destroy
> some of the contents of the original/provided string.
> ex. This is perfectly valid...
> {noformat}
> WITH LOGIN = false AND PASSWORD = 'bar' AND SUPERUSER = false
> {noformat}
> ...but calling obfuscate() on it will produce...
> {noformat}
> WITH LOGIN = false AND PASSWORD ***
> {noformat}
> -We should be able to create a reasonable RegEx and use String#replaceAll()
> to both simplify and correct PasswordObfuscator#obfuscate().-
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
