[jira] [Assigned] (CASSANDRA-17986) improve StartupException related codes
[
https://issues.apache.org/jira/browse/CASSANDRA-17986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kanthi Subramanian reassigned CASSANDRA-17986:
--
Assignee: Kanthi Subramanian
> improve StartupException related codes
> --
>
> Key: CASSANDRA-17986
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17986
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Other
>Reporter: Ling Mao
>Assignee: Kanthi Subramanian
>Priority: Normal
>
> 1. We should use the enum: _*ERR_WRONG_MACHINE_STATE*_ and
> *_ERR_WRONG_DISK_STATE_* to replace the magic number: 1 and 3
> {code:java}
> exitOrFail(1, e.getMessage(), e.getCause());
> exitOrFail(3, "Exception encountered during startup", e);{code}
>
> 2. Delete the useless field: *_ERR_OUTDATED_SCHEMA_*
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-17447) Add support for Alter materialized View in CQL3 statements
[ https://issues.apache.org/jira/browse/CASSANDRA-17447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kanthi Subramanian reassigned CASSANDRA-17447: -- Assignee: (was: Kanthi Subramanian) > Add support for Alter materialized View in CQL3 statements > -- > > Key: CASSANDRA-17447 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17447 > Project: Cassandra > Issue Type: Improvement > Components: CQL/Interpreter, CQL/Semantics >Reporter: Jogesh Anand >Priority: Normal > > Add support for ALTER MATERIALIZED VIEW stmts in CQL3. > Make changes to cql3handling.py and ensure correctness > Acceptance Criteria: > * should have the similar semantics as in parser.q antlr > * tests should run in python3 venv locally . refer: [development testing > wiki| https://cassandra.apache.org/_/development/testing.html ] > * check if additional tests need to be added in cassandra-dtests wrt to this > change -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-17447) Add support for Alter materialized View in CQL3 statements
[ https://issues.apache.org/jira/browse/CASSANDRA-17447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kanthi Subramanian reassigned CASSANDRA-17447: -- Assignee: Kanthi Subramanian > Add support for Alter materialized View in CQL3 statements > -- > > Key: CASSANDRA-17447 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17447 > Project: Cassandra > Issue Type: Improvement > Components: CQL/Interpreter, CQL/Semantics >Reporter: Jogesh Anand >Assignee: Kanthi Subramanian >Priority: Normal > > Add support for ALTER MATERIALIZED VIEW stmts in CQL3. > Make changes to cql3handling.py and ensure correctness > Acceptance Criteria: > * should have the similar semantics as in parser.q antlr > * tests should run in python3 venv locally . refer: [development testing > wiki| https://cassandra.apache.org/_/development/testing.html ] > * check if additional tests need to be added in cassandra-dtests wrt to this > change -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17021) Enhance Zstd support in Cassandra with dictionaries
[ https://issues.apache.org/jira/browse/CASSANDRA-17021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17618187#comment-17618187 ] Kanthi Subramanian commented on CASSANDRA-17021: [~yifanc] im happy to work on this if you are not > Enhance Zstd support in Cassandra with dictionaries > --- > > Key: CASSANDRA-17021 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17021 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Compression >Reporter: Dinesh Joshi >Assignee: Yifan Cai >Priority: Normal > > Currently Cassandra supports zstd compression. However, Zstd also supports > dictionaries to enhance not only the compression ratio but also the speed. > Dictionaries can show 3-4x savings. We should add support to train > dictionaries, ideally per SSTable this will yield the maximum gains. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-12937) Default setting (yaml) for SSTable compression
[
https://issues.apache.org/jira/browse/CASSANDRA-12937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kanthi Subramanian reassigned CASSANDRA-12937:
--
Assignee: (was: Kanthi Subramanian)
> Default setting (yaml) for SSTable compression
> --
>
> Key: CASSANDRA-12937
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12937
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Michael Semb Wever
>Priority: Low
> Labels: AdventCalendar2021, lhf
>
> In many situations the choice of compression for sstables is more relevant to
> the disks attached than to the schema and data.
> This issue is to add to cassandra.yaml a default value for sstable
> compression that new tables will inherit (instead of the defaults found in
> {{CompressionParams.DEFAULT}}.
> Examples where this can be relevant are filesystems that do on-the-fly
> compression (btrfs, zfs) or specific disk configurations or even specific C*
> versions (see CASSANDRA-10995 ).
> +Additional information for newcomers+
> Some new fields need to be added to {{cassandra.yaml}} to allow specifying
> the field required for defining the default compression parameters. In
> {{DatabaseDescriptor}} a new {{CompressionParams}} field should be added for
> the default compression. This field should be initialized in
> {{DatabaseDescriptor.applySimpleConfig()}}. At the different places where
> {{CompressionParams.DEFAULT}} was used the code should call
> {{DatabaseDescriptor#getDefaultCompressionParams}} that should return some
> copy of configured {{CompressionParams}}.
> Some unit test using {{OverrideConfigurationLoader}} should be used to test
> that the table schema use the new default when a new table is created (see
> CreateTest for some example).
--
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-17198) Allow to filter using LIKE predicates
[
https://issues.apache.org/jira/browse/CASSANDRA-17198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17491156#comment-17491156
]
Kanthi Subramanian commented on CASSANDRA-17198:
Hi [~blerer] , can you please take a look at the PR when u get a chance.
[https://github.com/apache/cassandra/pull/1373]
> 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
>Assignee: Kanthi Subramanian
>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] [Assigned] (CASSANDRA-16565) Remove dependency on sigar
[ https://issues.apache.org/jira/browse/CASSANDRA-16565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kanthi Subramanian reassigned CASSANDRA-16565: -- Assignee: (was: Kanthi Subramanian) > Remove dependency on sigar > -- > > Key: CASSANDRA-16565 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16565 > Project: Cassandra > Issue Type: Improvement > Components: Build >Reporter: David Capwell >Priority: Normal > > sigar is used to check if the environment has good settings for running C*, > but requires we bundle a lot of native libraries to perform this check (which > can also be done elsewhere). This project also appears to be dead as the > last commit was around 6 years ago. > With the move to resolve artifacts rather than commit them, removing this > dependency would remove majority of the artifacts fetched from GitHub. -- 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-17198) Allow to filter using LIKE predicates
[
https://issues.apache.org/jira/browse/CASSANDRA-17198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17487270#comment-17487270
]
Kanthi Subramanian commented on CASSANDRA-17198:
Hi [~bereng] , Added extra tests, please check when u get a chance.
> 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
>Assignee: Kanthi Subramanian
>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] [Commented] (CASSANDRA-17198) Allow to filter using LIKE predicates
[
https://issues.apache.org/jira/browse/CASSANDRA-17198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17477878#comment-17477878
]
Kanthi Subramanian commented on CASSANDRA-17198:
[~blerer] can u please take a look at the PR when u get a chance.
[https://github.com/apache/cassandra/pull/1373]
> 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
>Assignee: Kanthi Subramanian
>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] [Commented] (CASSANDRA-17198) Allow to filter using LIKE predicates
[
https://issues.apache.org/jira/browse/CASSANDRA-17198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17473096#comment-17473096
]
Kanthi Subramanian commented on CASSANDRA-17198:
Created PR with tests - [~blerer] , please take a look when u get a chance.
[https://github.com/apache/cassandra/pull/1373]
> 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
>Assignee: Kanthi Subramanian
>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] [Commented] (CASSANDRA-17198) Allow to filter using LIKE predicates
[
https://issues.apache.org/jira/browse/CASSANDRA-17198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17472978#comment-17472978
]
Kanthi Subramanian commented on CASSANDRA-17198:
Thanks Benjamin , will try that out
> 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
>Assignee: Kanthi Subramanian
>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] [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=17472815#comment-17472815
]
Kanthi Subramanian commented on CASSANDRA-17133:
Hi [~bereng] , As suggested by [~blerer] , the plan is to rollback the change.
I wanted to check if there is a way to revert it or I can create a PR that
removes those changes, please let me know.
> 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-17198) Allow to filter using LIKE predicates
[
https://issues.apache.org/jira/browse/CASSANDRA-17198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17472812#comment-17472812
]
Kanthi Subramanian commented on CASSANDRA-17198:
Hi [~blerer] ,
I modified CassandraIndex to get past this error
{code:java}
// code placeholder
select * from emp where emp_name like 'John%' allow filtering;
InvalidRequest: Error from server: code=2200 [Invalid query] message="emp_name
LIKE '%' John is only supported on properly indexed columns"
{code}
> 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
>Assignee: Kanthi Subramanian
>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] [Assigned] (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
]
Kanthi Subramanian reassigned CASSANDRA-9312:
-
Assignee: Kanthi Subramanian
> 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
>Assignee: Kanthi Subramanian
>Priority: Normal
> Labels: AdventCalendar2021, lhf
> 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 the {{writeTime}} and {{ttl}} methods on primary key columns. To do
> that you will need to:
> * remove the check of {{Selectable.WritetimeOrTTL}} preenting the use of
> {{writeTime}} and {{ttl}} methods on primary key columns
> * add a new method like {{add(ByteBuffer v, LivenessInfo livenessInfo, int
> nowInSec)}} to {{ResultSetBuilder}} that method should populate the value as
> well as the timestamps and ttls if needed
> * In {{SelectStatement.processPartition}} retrieve the row
> primaryKeyLivenessInfo and call the new {{ResultSetBuilder}} method with
> those information.
> * Adds some unit tests 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] [Assigned] (CASSANDRA-12937) Default setting (yaml) for SSTable compression
[
https://issues.apache.org/jira/browse/CASSANDRA-12937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kanthi Subramanian reassigned CASSANDRA-12937:
--
Assignee: Kanthi Subramanian
> Default setting (yaml) for SSTable compression
> --
>
> Key: CASSANDRA-12937
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12937
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Michael Semb Wever
>Assignee: Kanthi Subramanian
>Priority: Low
> Labels: AdventCalendar2021, lhf
>
> In many situations the choice of compression for sstables is more relevant to
> the disks attached than to the schema and data.
> This issue is to add to cassandra.yaml a default value for sstable
> compression that new tables will inherit (instead of the defaults found in
> {{CompressionParams.DEFAULT}}.
> Examples where this can be relevant are filesystems that do on-the-fly
> compression (btrfs, zfs) or specific disk configurations or even specific C*
> versions (see CASSANDRA-10995 ).
> +Additional information for newcomers+
> Some new fields need to be added to {{cassandra.yaml}} to allow specifying
> the field required for defining the default compression parameters. In
> {{DatabaseDescriptor}} a new {{CompressionParams}} field should be added for
> the default compression. This field should be initialized in
> {{DatabaseDescriptor.applySimpleConfig()}}. At the different places where
> {{CompressionParams.DEFAULT}} was used the code should call
> {{DatabaseDescriptor#getDefaultCompressionParams}} that should return some
> copy of configured {{CompressionParams}}.
> Some unit test using {{OverrideConfigurationLoader}} should be used to test
> that the table schema use the new default when a new table is created (see
> CreateTest for some example).
--
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-17198) Allow to filter using LIKE predicates
[
https://issues.apache.org/jira/browse/CASSANDRA-17198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17468124#comment-17468124
]
Kanthi Subramanian commented on CASSANDRA-17198:
[~blerer] I removed the restrictions here, but the like query doesnt work as
expected for example 'John%' doesnt work, any thoughts on where I should be
looking into. I did add an index.
[https://github.com/apache/cassandra/pull/1373/files]
{code:java}
// code placeholder
cqlsh:tutorialspoint> select * from emp where emp_name like 'John Doe%' allow
filtering; emp_id | date | emp_name
+---+--
1 | 1564830182000 | John Doe(1 rows)
cqlsh:tutorialspoint> select * from emp where emp_name like 'John%' allow
filtering; emp_id | date | emp_name
+--+--
{code}
> 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
>Assignee: Kanthi Subramanian
>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-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
]
Kanthi Subramanian updated CASSANDRA-16436:
---
Status: Patch Available (was: Open)
> 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
>Assignee: Kanthi Subramanian
>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] [Commented] (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:comment-tabpanel=17467679#comment-17467679
]
Kanthi Subramanian commented on CASSANDRA-16436:
[~paulo] addressed all the comments except the test and one change with reading
the file, please check PR when u get a chance.
> 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
>Assignee: Kanthi Subramanian
>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-17198) Allow to filter using LIKE predicates
[
https://issues.apache.org/jira/browse/CASSANDRA-17198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kanthi Subramanian reassigned CASSANDRA-17198:
--
Assignee: Kanthi Subramanian
> 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
>Assignee: Kanthi Subramanian
>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] [Assigned] (CASSANDRA-16640) Round out cqlsh completion test coverage
[ https://issues.apache.org/jira/browse/CASSANDRA-16640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kanthi Subramanian reassigned CASSANDRA-16640: -- Assignee: (was: Kanthi Subramanian) > Round out cqlsh completion test coverage > > > Key: CASSANDRA-16640 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16640 > Project: Cassandra > Issue Type: Improvement > Components: Test/unit >Reporter: Adam Holmberg >Priority: Low > Fix For: 4.0.x > > > There are some missing tests in cqlsh completion. Some highlighted > [here|https://github.com/apache/cassandra/blob/10a1d65eb09a93aee32948b46b4f1a0fbc2defe0/pylib/cqlshlib/test/test_cqlsh_completion.py#L808-L824]. > There might be more needing coverage that are not enumerated. -- 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-9430) Add startup options to cqlshrc
[
https://issues.apache.org/jira/browse/CASSANDRA-9430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kanthi Subramanian reassigned CASSANDRA-9430:
-
Assignee: (was: Kanthi Subramanian)
> Add startup options to cqlshrc
> --
>
> Key: CASSANDRA-9430
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9430
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Tools
>Reporter: Jeremy Hanna
>Priority: Low
> Labels: cqlsh, lhf
>
> There are certain settings that would be nice to set defaults for in the
> cqlshrc file. For example, a user may want to set the paging to off by
> default for their environment. You can't simply do
> {code}
> echo "paging off;" | cqlsh
> {code}
> because this would disable paging and immediately exit cqlsh.
> So it would be nice to have a section of the cqlshrc to include default
> settings on startup.
--
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
]
Kanthi Subramanian updated CASSANDRA-16436:
---
Status: Patch Available (was: In Progress)
> 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
>Assignee: Kanthi Subramanian
>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] [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=17457311#comment-17457311
]
Kanthi Subramanian commented on CASSANDRA-17133:
Thanks [~blerer] and [~brandon.williams] for reviewing it again, should I be
creating a PR to remove the functions and tests or is there anyway u can revert
the commit. Please let me know.
> 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] [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=17456834#comment-17456834
]
Kanthi Subramanian edited comment on CASSANDRA-17133 at 12/10/21, 1:33 AM:
---
[~brandon.williams] , I made the same change in the unit tests too, please see
here, because support for bigint was added to maxTimeuuid, the logic of picking
the right function throws the ambiguous error.
Its quite possible the user will encounter this, but I assumed its fine because
the other functions work the same way.
[https://github.com/apache/cassandra/pull/1275/files]
{code:java}
-- assertEmpty(execute("SELECT t FROM %s WHERE k = 0 AND t >
maxTimeuuid(1234567) AND t < minTimeuuid('2012-11-07 18:18:22-0800')"));
++ assertEmpty(execute("SELECT t FROM %s WHERE k = 0 AND t >
maxTimeuuid(1564830182000) AND t < minTimeuuid('2012-11-07 18:18:22-0800')"));
{code}
It obviously works when the number is bigint.
{code:java}
select maxTimeuuid(1564830182000) from emp; system.maxtimeuuid(1564830182000)
--
42d31e0f-b5de-11e9-7f7f-7f7f7f7f7f7f
{code}
The reason is this logic here,
Because bigint and timestamp gets the WEAKLY_ASSIGNABLE when the parameter is
integer.
https://issues.apache.org/jira/browse/CASSANDRA-17029
{code:java}
case INTEGER:
// code placeholdercase INTEGER:
switch (nt)
{
case BIGINT:
case COUNTER:
case DATE:
case DECIMAL:
case DOUBLE:
case DURATION:
case FLOAT:
case INT:
case SMALLINT:
case TIME:
case TIMESTAMP:
case TINYINT:
case VARINT:
return AssignmentTestable.TestResult.WEAKLY_ASSIGNABLE;
{code}
The tounixtimestamp function which wasnt changed as part of this PR also has
the same problem.
{code:java}
// code placeholder
select toUnixTimestamp(123) from emp;
InvalidRequest: Error from server: code=2200 [Invalid query] message="Ambiguous
call to function tounixtimestamp (can be matched by following signatures:
system.tounixtimestamp : (timestamp) -> bigint, system.tounixtimestamp : (date)
-> bigint): use type casts to disambiguate"
{code}
It will definitely be great if we can check for int and cast to bigint, but not
sure where it can be done because the testAssignment function is first called.
was (Author: subkanthi):
[~brandon.williams] , I made the same change in the unit tests too, please see
here, because support for bigint was added to maxTimeuuid, the logic of picking
the right function throws the ambiguous error.
Its quite possible the user will encounter this, but I assumed its fine because
the other functions work the same way.
[https://github.com/apache/cassandra/pull/1275/files]
{code:java}
-- assertEmpty(execute("SELECT t FROM %s WHERE k = 0 AND t >
maxTimeuuid(1234567) AND t < minTimeuuid('2012-11-07 18:18:22-0800')"));
++ assertEmpty(execute("SELECT t FROM %s WHERE k = 0 AND t >
maxTimeuuid(1564830182000) AND t < minTimeuuid('2012-11-07 18:18:22-0800')"));
{code}
The reason is this logic here,
Because bigint and timestamp gets the WEAKLY_ASSIGNABLE when the parameter is
integer.
https://issues.apache.org/jira/browse/CASSANDRA-17029
{code:java}
case INTEGER:
// code placeholdercase INTEGER:
switch (nt)
{
case BIGINT:
case COUNTER:
case DATE:
case DECIMAL:
case DOUBLE:
case DURATION:
case FLOAT:
case INT:
case SMALLINT:
case TIME:
case TIMESTAMP:
case TINYINT:
case VARINT:
return AssignmentTestable.TestResult.WEAKLY_ASSIGNABLE;
{code}
The tounixtimestamp function which wasnt changed as part of this PR also has
the same problem.
{code:java}
// code placeholder
select toUnixTimestamp(123) from emp;
InvalidRequest: Error from server: code=2200 [Invalid query] message="Ambiguous
call to function tounixtimestamp (can be matched by following signatures:
system.tounixtimestamp : (timestamp) -> bigint, system.tounixtimestamp : (date)
-> bigint): use type casts to disambiguate"
{code}
It will definitely be great if we can check for int and cast to bigint, but not
sure where it can be done because the testAssignment function is first called.
> 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
[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=17456834#comment-17456834
]
Kanthi Subramanian edited comment on CASSANDRA-17133 at 12/10/21, 1:32 AM:
---
[~brandon.williams] , I made the same change in the unit tests too, please see
here, because support for bigint was added to maxTimeuuid, the logic of picking
the right function throws the ambiguous error.
Its quite possible the user will encounter this, but I assumed its fine because
the other functions work the same way.
[https://github.com/apache/cassandra/pull/1275/files]
{code:java}
-- assertEmpty(execute("SELECT t FROM %s WHERE k = 0 AND t >
maxTimeuuid(1234567) AND t < minTimeuuid('2012-11-07 18:18:22-0800')"));
++ assertEmpty(execute("SELECT t FROM %s WHERE k = 0 AND t >
maxTimeuuid(1564830182000) AND t < minTimeuuid('2012-11-07 18:18:22-0800')"));
{code}
The reason is this logic here,
Because bigint and timestamp gets the WEAKLY_ASSIGNABLE when the parameter is
integer.
https://issues.apache.org/jira/browse/CASSANDRA-17029
{code:java}
case INTEGER:
// code placeholdercase INTEGER:
switch (nt)
{
case BIGINT:
case COUNTER:
case DATE:
case DECIMAL:
case DOUBLE:
case DURATION:
case FLOAT:
case INT:
case SMALLINT:
case TIME:
case TIMESTAMP:
case TINYINT:
case VARINT:
return AssignmentTestable.TestResult.WEAKLY_ASSIGNABLE;
{code}
The tounixtimestamp function which wasnt changed as part of this PR also has
the same problem.
{code:java}
// code placeholder
select toUnixTimestamp(123) from emp;
InvalidRequest: Error from server: code=2200 [Invalid query] message="Ambiguous
call to function tounixtimestamp (can be matched by following signatures:
system.tounixtimestamp : (timestamp) -> bigint, system.tounixtimestamp : (date)
-> bigint): use type casts to disambiguate"
{code}
It will definitely be great if we can check for int and cast to bigint, but not
sure where it can be done because the testAssignment function is first called.
was (Author: subkanthi):
[~brandon.williams] , I made the same change in the unit tests too, please see
here, because support for bigint was added to maxTimeuuid, the logic of picking
the right function throws the ambiguous error.
Its quite possible the user will encounter this, but I assumed that the other
functions work the same way.
[https://github.com/apache/cassandra/pull/1275/files]
{code:java}
-- assertEmpty(execute("SELECT t FROM %s WHERE k = 0 AND t >
maxTimeuuid(1234567) AND t < minTimeuuid('2012-11-07 18:18:22-0800')"));
++ assertEmpty(execute("SELECT t FROM %s WHERE k = 0 AND t >
maxTimeuuid(1564830182000) AND t < minTimeuuid('2012-11-07 18:18:22-0800')"));
{code}
The reason is this logic here,
Because bigint and timestamp gets the WEAKLY_ASSIGNABLE when the parameter is
integer.
https://issues.apache.org/jira/browse/CASSANDRA-17029
{code:java}
case INTEGER:
// code placeholdercase INTEGER:
switch (nt)
{
case BIGINT:
case COUNTER:
case DATE:
case DECIMAL:
case DOUBLE:
case DURATION:
case FLOAT:
case INT:
case SMALLINT:
case TIME:
case TIMESTAMP:
case TINYINT:
case VARINT:
return AssignmentTestable.TestResult.WEAKLY_ASSIGNABLE;
{code}
The tounixtimestamp function which wasnt changed as part of this PR also has
the same problem.
{code:java}
// code placeholder
select toUnixTimestamp(123) from emp;
InvalidRequest: Error from server: code=2200 [Invalid query] message="Ambiguous
call to function tounixtimestamp (can be matched by following signatures:
system.tounixtimestamp : (timestamp) -> bigint, system.tounixtimestamp : (date)
-> bigint): use type casts to disambiguate"
{code}
It will definitely be great if we can check for int and cast to bigint, but not
sure where it can be done because the testAssignment function is first called.
> 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
[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=17456834#comment-17456834
]
Kanthi Subramanian edited comment on CASSANDRA-17133 at 12/10/21, 1:28 AM:
---
[~brandon.williams] , I made the same change in the unit tests too, please see
here, because support for bigint was added to maxTimeuuid, the logic of picking
the right function throws the ambiguous error.
Its quite possible the user will encounter this, but I assumed that the other
functions work the same way.
[https://github.com/apache/cassandra/pull/1275/files]
{code:java}
-- assertEmpty(execute("SELECT t FROM %s WHERE k = 0 AND t >
maxTimeuuid(1234567) AND t < minTimeuuid('2012-11-07 18:18:22-0800')"));
++ assertEmpty(execute("SELECT t FROM %s WHERE k = 0 AND t >
maxTimeuuid(1564830182000) AND t < minTimeuuid('2012-11-07 18:18:22-0800')"));
{code}
The reason is this logic here,
Because bigint and timestamp gets the WEAKLY_ASSIGNABLE when the parameter is
integer.
https://issues.apache.org/jira/browse/CASSANDRA-17029
{code:java}
case INTEGER:
// code placeholdercase INTEGER:
switch (nt)
{
case BIGINT:
case COUNTER:
case DATE:
case DECIMAL:
case DOUBLE:
case DURATION:
case FLOAT:
case INT:
case SMALLINT:
case TIME:
case TIMESTAMP:
case TINYINT:
case VARINT:
return AssignmentTestable.TestResult.WEAKLY_ASSIGNABLE;
{code}
The tounixtimestamp function which wasnt changed as part of this PR also has
the same problem.
{code:java}
// code placeholder
select toUnixTimestamp(123) from emp;
InvalidRequest: Error from server: code=2200 [Invalid query] message="Ambiguous
call to function tounixtimestamp (can be matched by following signatures:
system.tounixtimestamp : (timestamp) -> bigint, system.tounixtimestamp : (date)
-> bigint): use type casts to disambiguate"
{code}
It will definitely be great if we can check for int and cast to bigint, but not
sure where it can be done because the testAssignment function is first called.
was (Author: subkanthi):
[~brandon.williams] , I made the same change in the unit tests too, please see
here, because support for bigint was added to maxTimeuuid, the logic of picking
the right function throws the ambiguous error.
Its quite possible the user will encounter this, but I assumed that the other
functions work the same way.
[https://github.com/apache/cassandra/pull/1275/files]
{code:java}
-- assertEmpty(execute("SELECT t FROM %s WHERE k = 0 AND t >
maxTimeuuid(1234567) AND t < minTimeuuid('2012-11-07 18:18:22-0800')"));
++ assertEmpty(execute("SELECT t FROM %s WHERE k = 0 AND t >
maxTimeuuid(1564830182000) AND t < minTimeuuid('2012-11-07 18:18:22-0800')"));
{code}
The reason is this logic here,
Because bigint and timestamp gets the WEAKLY_ASSIGNABLE when the parameter is
integer.
https://issues.apache.org/jira/browse/CASSANDRA-17029
{code:java}
case INTEGER:
// code placeholdercase INTEGER:
switch (nt)
{
case BIGINT:
case COUNTER:
case DATE:
case DECIMAL:
case DOUBLE:
case DURATION:
case FLOAT:
case INT:
case SMALLINT:
case TIME:
case TIMESTAMP:
case TINYINT:
case VARINT:
return AssignmentTestable.TestResult.WEAKLY_ASSIGNABLE;
{code}
> 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] [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=17456834#comment-17456834
]
Kanthi Subramanian edited comment on CASSANDRA-17133 at 12/10/21, 1:24 AM:
---
[~brandon.williams] , I made the same change in the unit tests too, please see
here, because support for bigint was added to maxTimeuuid, the logic of picking
the right function throws the ambiguous error.
Its quite possible the user will encounter this, but I assumed that the other
functions work the same way.
[https://github.com/apache/cassandra/pull/1275/files]
{code:java}
-- assertEmpty(execute("SELECT t FROM %s WHERE k = 0 AND t >
maxTimeuuid(1234567) AND t < minTimeuuid('2012-11-07 18:18:22-0800')"));
++ assertEmpty(execute("SELECT t FROM %s WHERE k = 0 AND t >
maxTimeuuid(1564830182000) AND t < minTimeuuid('2012-11-07 18:18:22-0800')"));
{code}
The reason is this logic here,
Because bigint and timestamp gets the WEAKLY_ASSIGNABLE when the parameter is
integer.
https://issues.apache.org/jira/browse/CASSANDRA-17029
{code:java}
case INTEGER:
// code placeholdercase INTEGER:
switch (nt)
{
case BIGINT:
case COUNTER:
case DATE:
case DECIMAL:
case DOUBLE:
case DURATION:
case FLOAT:
case INT:
case SMALLINT:
case TIME:
case TIMESTAMP:
case TINYINT:
case VARINT:
return AssignmentTestable.TestResult.WEAKLY_ASSIGNABLE;
{code}
was (Author: subkanthi):
[~brandon.williams] , I made the same change in the unit tests too, please see
here, because support for bigint was added to maxTimeuuid, the logic of picking
the right function throws the ambiguous error.
Its quite possible the user will encounter this, but I assumed that the other
functions work the same way.
[https://github.com/apache/cassandra/pull/1275/files]
{code:java}
-- assertEmpty(execute("SELECT t FROM %s WHERE k = 0 AND t >
maxTimeuuid(1234567) AND t < minTimeuuid('2012-11-07 18:18:22-0800')"));
++ assertEmpty(execute("SELECT t FROM %s WHERE k = 0 AND t >
maxTimeuuid(1564830182000) AND t < minTimeuuid('2012-11-07 18:18:22-0800')"));
{code}
The reason is this logic here,
Because bigint and timestamp gets the WEAKLY_ASSIGNABLE when the parameter is
integer.
https://issues.apache.org/jira/browse/CASSANDRA-17029
{code:java}
// code placeholdercase INTEGER:
switch (nt)
{
case BIGINT:
case COUNTER:
case DATE:
case DECIMAL:
case DOUBLE:
case DURATION:
case FLOAT:
case INT:
case SMALLINT:
case TIME:
case TIMESTAMP:
case TINYINT:
case VARINT:
return AssignmentTestable.TestResult.WEAKLY_ASSIGNABLE;
{code}
> 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] [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=17456834#comment-17456834
]
Kanthi Subramanian edited comment on CASSANDRA-17133 at 12/10/21, 1:19 AM:
---
[~brandon.williams] , I made the same change in the unit tests too, please see
here, because support for bigint was added to maxTimeuuid, the logic of picking
the right function throws the ambiguous error.
Its quite possible the user will encounter this, but I assumed that the other
functions work the same way.
[https://github.com/apache/cassandra/pull/1275/files]
{code:java}
-- assertEmpty(execute("SELECT t FROM %s WHERE k = 0 AND t >
maxTimeuuid(1234567) AND t < minTimeuuid('2012-11-07 18:18:22-0800')"));
++ assertEmpty(execute("SELECT t FROM %s WHERE k = 0 AND t >
maxTimeuuid(1564830182000) AND t < minTimeuuid('2012-11-07 18:18:22-0800')"));
{code}
The reason is this logic here,
Because bigint and timestamp gets the WEAKLY_ASSIGNABLE when the parameter is
integer.
https://issues.apache.org/jira/browse/CASSANDRA-17029
{code:java}
// code placeholdercase INTEGER:
switch (nt)
{
case BIGINT:
case COUNTER:
case DATE:
case DECIMAL:
case DOUBLE:
case DURATION:
case FLOAT:
case INT:
case SMALLINT:
case TIME:
case TIMESTAMP:
case TINYINT:
case VARINT:
return AssignmentTestable.TestResult.WEAKLY_ASSIGNABLE;
{code}
was (Author: subkanthi):
[~brandon.williams] , I made the same change in the unit tests too, please see
here, because support for bigint was added to maxTimeuuid, the logic of picking
the right function throws the ambiguous error.
Its quite possible the user will encounter this, but I assumed that the other
functions work the same way.
[https://github.com/apache/cassandra/pull/1275/files]
{code:java}
-- assertEmpty(execute("SELECT t FROM %s WHERE k = 0 AND t >
maxTimeuuid(1234567) AND t < minTimeuuid('2012-11-07 18:18:22-0800')"));
++ assertEmpty(execute("SELECT t FROM %s WHERE k = 0 AND t >
maxTimeuuid(1564830182000) AND t < minTimeuuid('2012-11-07 18:18:22-0800')"));
{code}
The reason is this logic here,
Because bigint and timestamp gets the WEAKLY_ASSIGNABLE when the parameter is
integer.
https://issues.apache.org/jira/browse/CASSANDRA-17029
{code:java}
// code placeholdercase INTEGER:
switch (nt)
{
case BIGINT:
case COUNTER:
case DATE:
case DECIMAL:
case DOUBLE:
case DURATION:
case FLOAT:
case INT:
case SMALLINT:
case TIME:
case TIMESTAMP:
case TINYINT:
case VARINT:
return AssignmentTestable.TestResult.WEAKLY_ASSIGNABLE;
{code}
> 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] [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=17456834#comment-17456834
]
Kanthi Subramanian edited comment on CASSANDRA-17133 at 12/10/21, 1:17 AM:
---
[~brandon.williams] , I made the same change in the unit tests too, please see
here, because support for bigint was added to maxTimeuuid, the logic of picking
the right function throws the ambiguous error.
Its quite possible the user will encounter this, but I assumed that the other
functions work the same way.
[https://github.com/apache/cassandra/pull/1275/files]
{code:java}
-- assertEmpty(execute("SELECT t FROM %s WHERE k = 0 AND t >
maxTimeuuid(1234567) AND t < minTimeuuid('2012-11-07 18:18:22-0800')"));
++ assertEmpty(execute("SELECT t FROM %s WHERE k = 0 AND t >
maxTimeuuid(1564830182000) AND t < minTimeuuid('2012-11-07 18:18:22-0800')"));
{code}
The reason is this logic here,
Because bigint and timestamp gets the WEAKLY_ASSIGNABLE when the parameter is
integer.
https://issues.apache.org/jira/browse/CASSANDRA-17029
{code:java}
// code placeholdercase INTEGER:
switch (nt)
{
case BIGINT:
case COUNTER:
case DATE:
case DECIMAL:
case DOUBLE:
case DURATION:
case FLOAT:
case INT:
case SMALLINT:
case TIME:
case TIMESTAMP:
case TINYINT:
case VARINT:
return AssignmentTestable.TestResult.WEAKLY_ASSIGNABLE;
{code}
was (Author: subkanthi):
[~brandon.williams] , I made the same change in the unit tests too, please see
here, because support for bigint was added to maxTimeuuid, the logic of picking
the right function throws the ambiguous error.
Its quite possible the user will encounter this, but I assumed that the other
functions work the same way, I will dig for the code that selects the function
based on the data type.
[https://github.com/apache/cassandra/pull/1275/files]
{code:java}
-- assertEmpty(execute("SELECT t FROM %s WHERE k = 0 AND t >
maxTimeuuid(1234567) AND t < minTimeuuid('2012-11-07 18:18:22-0800')"));
++ assertEmpty(execute("SELECT t FROM %s WHERE k = 0 AND t >
maxTimeuuid(1564830182000) AND t < minTimeuuid('2012-11-07 18:18:22-0800')"));
{code}
// code placeholdercase INTEGER:
switch (nt)
{
case BIGINT:
case COUNTER:
case DATE:
case DECIMAL:
case DOUBLE:
case DURATION:
case FLOAT:
case INT:
case SMALLINT:
case TIME:
case TIMESTAMP:
case TINYINT:
case VARINT:
return AssignmentTestable.TestResult.WEAKLY_ASSIGNABLE;
> 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] [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=17456834#comment-17456834
]
Kanthi Subramanian edited comment on CASSANDRA-17133 at 12/10/21, 1:16 AM:
---
[~brandon.williams] , I made the same change in the unit tests too, please see
here, because support for bigint was added to maxTimeuuid, the logic of picking
the right function throws the ambiguous error.
Its quite possible the user will encounter this, but I assumed that the other
functions work the same way, I will dig for the code that selects the function
based on the data type.
[https://github.com/apache/cassandra/pull/1275/files]
{code:java}
-- assertEmpty(execute("SELECT t FROM %s WHERE k = 0 AND t >
maxTimeuuid(1234567) AND t < minTimeuuid('2012-11-07 18:18:22-0800')"));
++ assertEmpty(execute("SELECT t FROM %s WHERE k = 0 AND t >
maxTimeuuid(1564830182000) AND t < minTimeuuid('2012-11-07 18:18:22-0800')"));
{code}
// code placeholdercase INTEGER:
switch (nt)
{
case BIGINT:
case COUNTER:
case DATE:
case DECIMAL:
case DOUBLE:
case DURATION:
case FLOAT:
case INT:
case SMALLINT:
case TIME:
case TIMESTAMP:
case TINYINT:
case VARINT:
return AssignmentTestable.TestResult.WEAKLY_ASSIGNABLE;
was (Author: subkanthi):
[~brandon.williams] , I made the same change in the unit tests too, please see
here, because support for bigint was added to maxTimeuuid, the logic of picking
the right function throws the ambiguous error.
Its quite possible the user will encounter this, but I assumed that the other
functions work the same way, I will dig for the code that selects the function
based on the data type.
[https://github.com/apache/cassandra/pull/1275/files]
{code:java}
-- assertEmpty(execute("SELECT t FROM %s WHERE k = 0 AND t >
maxTimeuuid(1234567) AND t < minTimeuuid('2012-11-07 18:18:22-0800')"));
++ assertEmpty(execute("SELECT t FROM %s WHERE k = 0 AND t >
maxTimeuuid(1564830182000) AND t < minTimeuuid('2012-11-07 18:18:22-0800')"));
{code}
> 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] [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=17456834#comment-17456834
]
Kanthi Subramanian edited comment on CASSANDRA-17133 at 12/10/21, 1:14 AM:
---
[~brandon.williams] , I made the same change in the unit tests too, please see
here, because support for bigint was added to maxTimeuuid, the logic of picking
the right function throws the ambiguous error.
Its quite possible the user will encounter this, but I assumed that the other
functions work the same way, I will dig for the code that selects the function
based on the data type.
[https://github.com/apache/cassandra/pull/1275/files]
{code:java}
-- assertEmpty(execute("SELECT t FROM %s WHERE k = 0 AND t >
maxTimeuuid(1234567) AND t < minTimeuuid('2012-11-07 18:18:22-0800')"));
++ assertEmpty(execute("SELECT t FROM %s WHERE k = 0 AND t >
maxTimeuuid(1564830182000) AND t < minTimeuuid('2012-11-07 18:18:22-0800')"));
{code}
was (Author: subkanthi):
[~brandon.williams] , I made the same change in the unit tests too, please see
here, because support for bigint was added to maxTimeuuid, the logic of picking
the right function throws the ambiguous error.
[https://github.com/apache/cassandra/pull/1275/files]
{code:java}
-- assertEmpty(execute("SELECT t FROM %s WHERE k = 0 AND t >
maxTimeuuid(1234567) AND t < minTimeuuid('2012-11-07 18:18:22-0800')"));
++ assertEmpty(execute("SELECT t FROM %s WHERE k = 0 AND t >
maxTimeuuid(1564830182000) AND t < minTimeuuid('2012-11-07 18:18:22-0800')"));
{code}
> 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=17456834#comment-17456834
]
Kanthi Subramanian commented on CASSANDRA-17133:
[~brandon.williams] , I made the same change in the unit tests too, please see
here, because support for bigint was added to maxTimeuuid, the logic of picking
the right function throws the ambiguous error.
[https://github.com/apache/cassandra/pull/1275/files]
{code:java}
-- assertEmpty(execute("SELECT t FROM %s WHERE k = 0 AND t >
maxTimeuuid(1234567) AND t < minTimeuuid('2012-11-07 18:18:22-0800')"));
++ assertEmpty(execute("SELECT t FROM %s WHERE k = 0 AND t >
maxTimeuuid(1564830182000) AND t < minTimeuuid('2012-11-07 18:18:22-0800')"));
{code}
> 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] [Updated] (CASSANDRA-17133) Broken test_timeuuid - upgrade_tests.cql_tests
[
https://issues.apache.org/jira/browse/CASSANDRA-17133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kanthi Subramanian updated CASSANDRA-17133:
---
Test and Documentation Plan:
Created PR here.
https://github.com/apache/cassandra-dtest/pull/171/files
Status: Patch Available (was: In Progress)
> 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] (CASSANDRA-16436) Add startup check for large read_ahead_kb setting
[ https://issues.apache.org/jira/browse/CASSANDRA-16436 ]
Kanthi Subramanian deleted comment on CASSANDRA-16436:
was (Author: subkanthi):
https://github.com/apache/cassandra/pull/1354
> 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
>Assignee: Kanthi Subramanian
>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] [Comment Edited] (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:comment-tabpanel=17453644#comment-17453644
]
Kanthi Subramanian edited comment on CASSANDRA-16436 at 12/5/21, 6:23 PM:
--
Added PR - https://github.com/apache/cassandra/pull/1354
was (Author: subkanthi):
[~paulo] Does this have to be added in startupChecks.java, I can give it a shot
DEFAULT_TESTS
> 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
>Assignee: Kanthi Subramanian
>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-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
]
Kanthi Subramanian updated CASSANDRA-16436:
---
Test and Documentation Plan: https://github.com/apache/cassandra/pull/1354
Status: Patch Available (was: In Progress)
https://github.com/apache/cassandra/pull/1354
> 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
>Assignee: Kanthi Subramanian
>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
]
Kanthi Subramanian reassigned CASSANDRA-16436:
--
Assignee: Kanthi Subramanian
> 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
>Assignee: Kanthi Subramanian
>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] [Commented] (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:comment-tabpanel=17453644#comment-17453644
]
Kanthi Subramanian commented on CASSANDRA-16436:
[~paulo] Does this have to be added in startupChecks.java, I can give it a shot
DEFAULT_TESTS
> 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] [Commented] (CASSANDRA-16565) Remove dependency on sigar
[ https://issues.apache.org/jira/browse/CASSANDRA-16565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17452492#comment-17452492 ] Kanthi Subramanian commented on CASSANDRA-16565: Looking at this more, oshi might cover most of the scenarios, the management API seems to have changed quite a bit over the java versions. Should there a new discussion thread started somewhere to pick the right library? > Remove dependency on sigar > -- > > Key: CASSANDRA-16565 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16565 > Project: Cassandra > Issue Type: Improvement > Components: Build >Reporter: David Capwell >Assignee: Kanthi Subramanian >Priority: Normal > > sigar is used to check if the environment has good settings for running C*, > but requires we bundle a lot of native libraries to perform this check (which > can also be done elsewhere). This project also appears to be dead as the > last commit was around 6 years ago. > With the move to resolve artifacts rather than commit them, removing this > dependency would remove majority of the artifacts fetched from GitHub. -- 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-16903) UDTs named after built-in data types
[ https://issues.apache.org/jira/browse/CASSANDRA-16903?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kanthi Subramanian reassigned CASSANDRA-16903: -- Assignee: (was: Kanthi Subramanian) > UDTs named after built-in data types > > > Key: CASSANDRA-16903 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16903 > Project: Cassandra > Issue Type: Bug > Components: Feature/UDT >Reporter: Brandon Bordeaux >Priority: Normal > Fix For: 4.0.x > > > Working with Cassandra 4.0 I found UDTs can be named after some built-in data > type, like map, list, and tuple, but not for other types, like text or set. > This behavior should be consistent across all built-in types where Cassandra > shouldn't allow a UDT to be named after any built-in type. > Having UDTs named after built-in types cause confusion working with table > schemas and may introduce downstream issues when Cassandra works with these > types. -- 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-14466) Enable Direct I/O
[ https://issues.apache.org/jira/browse/CASSANDRA-14466?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17449883#comment-17449883 ] Kanthi Subramanian commented on CASSANDRA-14466: Is this being worked on, I can try to rebase the PR again. > Enable Direct I/O > -- > > Key: CASSANDRA-14466 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14466 > Project: Cassandra > Issue Type: New Feature > Components: Legacy/Local Write-Read Paths >Reporter: Mulugeta Mammo >Priority: Normal > Fix For: 4.x > > > Hi, > JDK 10 introduced a new API for Direct IO that enables applications to bypass > the file system cache and potentially improve performance. Details of this > feature can be found at [https://bugs.openjdk.java.net/browse/JDK-8164900]. > This patch uses the JDK 10 API to enable Direct IO for the Cassandra read > path. By default, we have disabled this feature; but it can be enabled using > a new configuration parameter, enable_direct_io_for_read_path. We have > conducted a Cassandra read-only stress test and measured a throughput gain of > up to 60% on flash drives. > The patch requires JDK 10 Cassandra Support - > https://issues.apache.org/jira/browse/CASSANDRA-9608 > Please review the patch and let us know your feedback. > Thanks, > [^direct_io.patch] > -- 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-16565) Remove dependency on sigar
[ https://issues.apache.org/jira/browse/CASSANDRA-16565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17449719#comment-17449719 ] Kanthi Subramanian edited comment on CASSANDRA-16565 at 11/27/21, 12:54 PM: [~brandon.williams] , would shell script cover all operating systems, I just checked functionality for swap space, it looks like it might be a different logic for mac Os and for linux. Is java management API an option - [https://stackoverflow.com/questions/47177/how-do-i-monitor-the-computers-cpu-memory-and-disk-usage-in-java] Also is the plan to just remove Sigar without implementing warnIfRunningInDegradedMode? Also is this library an option - [https://github.com/oshi/oshi] was (Author: subkanthi): [~brandon.williams] , would shell script cover all operating systems, I just checked functionality for swap space, it looks like it might be a different logic for mac Os and for linux. Is java management API an option - [https://stackoverflow.com/questions/47177/how-do-i-monitor-the-computers-cpu-memory-and-disk-usage-in-java] Also is the plan to just remove Sigar without implementing warnIfRunningInDegradedMode? > Remove dependency on sigar > -- > > Key: CASSANDRA-16565 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16565 > Project: Cassandra > Issue Type: Improvement > Components: Build >Reporter: David Capwell >Assignee: Kanthi Subramanian >Priority: Normal > > sigar is used to check if the environment has good settings for running C*, > but requires we bundle a lot of native libraries to perform this check (which > can also be done elsewhere). This project also appears to be dead as the > last commit was around 6 years ago. > With the move to resolve artifacts rather than commit them, removing this > dependency would remove majority of the artifacts fetched from GitHub. -- 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-16565) Remove dependency on sigar
[ https://issues.apache.org/jira/browse/CASSANDRA-16565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17449719#comment-17449719 ] Kanthi Subramanian commented on CASSANDRA-16565: [~brandon.williams] , would shell script cover all operating systems, I just checked functionality for swap space, it looks like it might be a different logic for mac Os and for linux. Is java management API an option - [https://stackoverflow.com/questions/47177/how-do-i-monitor-the-computers-cpu-memory-and-disk-usage-in-java] Also is the plan to just remove Sigar without implementing warnIfRunningInDegradedMode? > Remove dependency on sigar > -- > > Key: CASSANDRA-16565 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16565 > Project: Cassandra > Issue Type: Improvement > Components: Build >Reporter: David Capwell >Assignee: Kanthi Subramanian >Priority: Normal > > sigar is used to check if the environment has good settings for running C*, > but requires we bundle a lot of native libraries to perform this check (which > can also be done elsewhere). This project also appears to be dead as the > last commit was around 6 years ago. > With the move to resolve artifacts rather than commit them, removing this > dependency would remove majority of the artifacts fetched from GitHub. -- 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-16565) Remove dependency on sigar
[ https://issues.apache.org/jira/browse/CASSANDRA-16565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kanthi Subramanian reassigned CASSANDRA-16565: -- Assignee: Kanthi Subramanian > Remove dependency on sigar > -- > > Key: CASSANDRA-16565 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16565 > Project: Cassandra > Issue Type: Improvement > Components: Build >Reporter: David Capwell >Assignee: Kanthi Subramanian >Priority: Normal > > sigar is used to check if the environment has good settings for running C*, > but requires we bundle a lot of native libraries to perform this check (which > can also be done elsewhere). This project also appears to be dead as the > last commit was around 6 years ago. > With the move to resolve artifacts rather than commit them, removing this > dependency would remove majority of the artifacts fetched from GitHub. -- 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-15281) help for clearsnapshot needs to be updated to indicate requirement for --all
[
https://issues.apache.org/jira/browse/CASSANDRA-15281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17449715#comment-17449715
]
Kanthi Subramanian commented on CASSANDRA-15281:
Already see the all option, does this ticket still apply
NAME
nodetool clearsnapshot - Remove the snapshot with the given name from
the given keyspaces
SYNOPSIS
nodetool [(-h | --host )] [(-p | --port )]
[(-pp | --print-port)] [(-pw | --password
)]
[(-pwf | --password-file )]
[(-u | --username )] clearsnapshot [--all]
[-t ] [--] [...]
OPTIONS
--all
Removes all snapshots
> help for clearsnapshot needs to be updated to indicate requirement for --all
>
>
> Key: CASSANDRA-15281
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15281
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/nodetool
>Reporter: DeepakVohra
>Priority: Normal
> Fix For: 4.x
>
> Attachments: 15281.trunk
>
>
> According to _CASSANDRA-13391_
> _nodetool clearsnapshot should require --all to clear all snapshots_
> But the help for clearsnapshot does not indicate the same.
> {code:java}
> [ec2-user@ip-10-0-2-238 ~]$ nodetool help clearsnapshot
> NAME nodetool clearsnapshot - Remove the snapshot with the given name from
> the given keyspaces. If no snapshotName is specified we will remove all
> snapshots{code}
> The help for clearsnapshot needs to be updated to indicate requirement for
> --all to remove all snapshots.
--
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=17449713#comment-17449713
]
Kanthi Subramanian commented on CASSANDRA-17133:
[~yifanc] , [~brandon.williams] , cannot find this test in cassandra codebase,
can you please let me know where I can find the tests and how to run it locally.
{code:java}
// code placeholder
def test_timeuuid(self):
cursor = self.prepare()
cursor.execute("""
CREATE TABLE test (
k int,
t timeuuid,
PRIMARY KEY (k, t)
)
""") {code}
> 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=17446924#comment-17446924
]
Kanthi Subramanian commented on CASSANDRA-17133:
[~yifanc] will take a look, sorry for some reason Im not notified by email when
tagged.
> 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
>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] [Assigned] (CASSANDRA-17133) Broken test_timeuuid - upgrade_tests.cql_tests
[
https://issues.apache.org/jira/browse/CASSANDRA-17133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kanthi Subramanian reassigned CASSANDRA-17133:
--
Assignee: Kanthi Subramanian
> 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-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=17438815#comment-17438815
]
Kanthi Subramanian commented on CASSANDRA-17120:
Looks like the condition that fails is *parsed <= now + threshold*
_assertTrue_("'now' timestamp not within expected tolerance.", now <= parsed &&
parsed <= now + threshold);
INFO [main] 2021-11-04 12:12:43,816 SubstituteLogger.java:169 - now1636042363752
INFO [main] 2021-11-04 12:12:43,819 SubstituteLogger.java:169 -
parsed1636042363765
> 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.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17029) Add unix time conversion functions
[
https://issues.apache.org/jira/browse/CASSANDRA-17029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17437629#comment-17437629
]
Kanthi Subramanian edited comment on CASSANDRA-17029 at 11/2/21, 10:28 PM:
---
Fixed the unit test to pass a long to maxTimeUUid
[~blerer] can u please check.
was (Author: subkanthi):
Fixed the unit test to pass a long to maxTimeUUid
> 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=17437629#comment-17437629
]
Kanthi Subramanian commented on CASSANDRA-17029:
Fixed the unit test to pass a long to maxTimeUUid
> 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=17436350#comment-17436350
]
Kanthi Subramanian commented on CASSANDRA-17029:
[~blerer], it works fine if the parameter passed is long, should I update the
test case?
{code:java}
// code placeholder
select maxTimeUuid(1564830182000) from emp; system.maxtimeuuid(1564830182000)
--
42d31e0f-b5de-11e9-7f7f-7f7f7f7f7f7f
{code}
> 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=17436346#comment-17436346
]
Kanthi Subramanian commented on CASSANDRA-17029:
{code:java}
// code placeholder
case INTEGER:
switch (nt)
{
case BIGINT:
case COUNTER:
case DATE:
case DECIMAL:
case DOUBLE:
case DURATION:
case FLOAT:
case INT:
case SMALLINT:
case TIME:
case TIMESTAMP:
case TINYINT:
case VARINT:
return AssignmentTestable.TestResult.WEAKLY_ASSIGNABLE;
{code}
Looks like both bigint and timestamp gets the WEAKLY_ASSIGNABLE when the
parameter is integer.
> 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=17435123#comment-17435123 ] Kanthi Subramanian commented on CASSANDRA-17029: [~blerer] Actually nvm the comment above, the rebase only fixes the first timestamp test, I was able to reproduce the ambiguous function in the validations test, trying to fix it. org.apache.cassandra.exceptions.InvalidRequestException: Ambiguous call to function maxtimeuuid (can be matched by following signatures: system.maxtimeuuid : (timestamp) -> timeuuid, system.maxtimeuuid : (bigint) -> timeuuid): use type casts to disambiguateorg.apache.cassandra.exceptions.InvalidRequestException: Ambiguous call to function maxtimeuuid (can be matched by following signatures: system.maxtimeuuid : (timestamp) -> timeuuid, system.maxtimeuuid : (bigint) -> timeuuid): use type casts to disambiguate at org.apache.cassandra.cql3.statements.RequestValidations.invalidRequest(RequestValidations.java:217) at org.apache.cassandra.cql3.functions.FunctionResolver.pickBestMatch(FunctionResolver.java:187) at org.apache.cassandra.cql3.functions.FunctionResolver.get(FunctionResolver.java:85) at org.apache.cassandra.cql3.functions.FunctionCall$Raw.prepare(FunctionCall.java:159) at org.apache.cassandra.cql3.SingleColumnRelation.toTerm(SingleColumnRelation.java:123) at org.apache.cassandra.cql3.SingleColumnRelation.newSliceRestriction(SingleColumnRelation.java:231) at org.apache.cassandra.cql3.Relation.toRestriction(Relation.java:147) at org.apache.cassandra.cql3.restrictions.StatementRestrictions.(StatementRestrictions.java:188) at org.apache.cassandra.cql3.restrictions.StatementRestrictions.(StatementRestrictions.java:135) at org.apache.cassandra.cql3.statements.SelectStatement$RawStatement.prepareRestrictions(SelectStatement.java:1134) at org.apache.cassandra.cql3.statements.SelectStatement$RawStatement.prepare(SelectStatement.java:1004) at org.apache.cassandra.cql3.statements.SelectStatement$RawStatement.prepare(SelectStatement.java:994) at org.apache.cassandra.cql3.statements.SelectStatement$RawStatement.prepare(SelectStatement.java:969) at org.apache.cassandra.cql3.QueryProcessor.getStatement(QueryProcessor.java:591) at org.apache.cassandra.cql3.QueryProcessor.parseStatement(QueryProcessor.java:276) at org.apache.cassandra.cql3.QueryProcessor.prepareInternal(QueryProcessor.java:324) at org.apache.cassandra.cql3.QueryProcessor.executeInternal(QueryProcessor.java:334) at org.apache.cassandra.cql3.CQLTester.executeFormattedQuery(CQLTester.java:1156) at org.apache.cassandra.cql3.CQLTester.execute(CQLTester.java:1144) at org.apache.cassandra.cql3.validation.entities.TimeuuidTest.testTimeuuid(TimeuuidTest.java:67) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:566) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) at org.junit.runners.ParentRunner.run(ParentRunner.java:363) at org.junit.runner.JUnitCore.run(JUnitCore.java:137) at com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:69) at com.intellij.rt.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:33) at com.intellij.rt.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:235) at com.intellij.rt.junit.JUnitStarter.main(JUnitStarter.java:54) > Add unix time conversion functions > -- > >
[jira] [Assigned] (CASSANDRA-14160) maxPurgeableTimestamp should traverse tables in order of minTimestamp
[ https://issues.apache.org/jira/browse/CASSANDRA-14160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kanthi Subramanian reassigned CASSANDRA-14160: -- Assignee: Kanthi Subramanian > maxPurgeableTimestamp should traverse tables in order of minTimestamp > - > > Key: CASSANDRA-14160 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14160 > Project: Cassandra > Issue Type: Bug > Components: Local/Compaction >Reporter: Josh Snyder >Assignee: Kanthi Subramanian >Priority: Normal > Labels: performance > Fix For: 4.x > > > In maxPurgeableTimestamp, we iterate over the bloom filters of each > overlapping SSTable. Of the bloom filter hits, we take the SSTable with the > lowest minTimestamp. If we kept the SSTables in sorted order of minTimestamp, > then we could short-circuit the operation at the first bloom filter hit, > reducing cache pressure (or worse, I/O) and CPU time. > I've written (but not yet benchmarked) [some > code|https://github.com/hashbrowncipher/cassandra/commit/29859a4a2e617f6775be49448858bc59fdafab44] > to demonstrate this possibility. -- 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=17435046#comment-17435046
]
Kanthi Subramanian commented on CASSANDRA-17029:
[~blerer], looks like those tests were fixed in trunk, rebased and pushed this
branch, tests run fine locally.
cc: [~brandon.williams]
> 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] [Assigned] (CASSANDRA-16513) Add tool to display or export the contents of a virtual table
[
https://issues.apache.org/jira/browse/CASSANDRA-16513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kanthi Subramanian reassigned CASSANDRA-16513:
--
Assignee: Kanthi Subramanian
> Add tool to display or export the contents of a virtual table
> -
>
> Key: CASSANDRA-16513
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16513
> Project: Cassandra
> Issue Type: Improvement
> Components: Observability/Metrics, Tool/nodetool
>Reporter: Paulo Motta
>Assignee: Kanthi Subramanian
>Priority: Normal
> Labels: gsoc2021, mentor
>
> Several virtual tables were recently added, but they're currently only
> accessible via cqlsh or programmatically. While this is valuable for many use
> cases, operators are accustomed with the convenience of querying system
> metrics with a simple nodetool command.
> In addition to that, a relatively common request is to provide nodetool
> output in different formats (JSON, YAML and even XML) (CASSANDRA-5977,
> CASSANDRA-12035, CASSANDRA-12486, CASSANDRA-12698, CASSANDRA-12503). However
> this requires lots of manual labor as each nodetool subcommand needs to be
> adapted to support new output formats.
> I propose adding a new CLI tool that will consistently print to the standard
> output the contents of a virtual table. By default the command will print the
> output in a tabular format similar to cqlsh, but a "--format" parameter can
> be specified to modify the output to some other format like JSON or YAML.
> It should be possible to add a limit to the amount of rows displayed and
> filter to display only rows from with specific keys (ie. keyspace or table).
> The command should be flexible and provide simple hooks for registration and
> customization of new virtual tables.
> My vision is that this is a path towards deprecating JMX and toward CQL for
> management, as we move information currently available through JMX to virtual
> tables (as CASSANDRA-14457 did with compactionstats) and easily expose them
> in this new tool as more virtual tables are added. Eventually we can also add
> setters when we start supporting writeable virtual tables.
> I propose calling this tool admintool (naming bikeshedding welcome), for
> example:
> {noformat}
> admintool help
> admintool
> Available subcommands and entities are:
> subcommands:
> - show
> - set (future)
> entities:
> - caches
> - internode_inbound
> - internode_outbound
> - settings
> - sstable_tasks
> - system_properties
> - thread_pools
> nodetool show clients --format yaml
> ...
> nodetool show internode_outboud --format json
> ...
> nodetool show sstabletasks --filter keyspace=my_ks --filter table=my_table
> ...
> {noformat}
--
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] [Assigned] (CASSANDRA-16640) Round out cqlsh completion test coverage
[ https://issues.apache.org/jira/browse/CASSANDRA-16640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kanthi Subramanian reassigned CASSANDRA-16640: -- Assignee: Kanthi Subramanian > Round out cqlsh completion test coverage > > > Key: CASSANDRA-16640 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16640 > Project: Cassandra > Issue Type: Improvement > Components: Test/unit >Reporter: Adam Holmberg >Assignee: Kanthi Subramanian >Priority: Low > Fix For: 4.0.x > > > There are some missing tests in cqlsh completion. Some highlighted > [here|https://github.com/apache/cassandra/blob/10a1d65eb09a93aee32948b46b4f1a0fbc2defe0/pylib/cqlshlib/test/test_cqlsh_completion.py#L808-L824]. > There might be more needing coverage that are not enumerated. -- 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-14160) maxPurgeableTimestamp should traverse tables in order of minTimestamp
[ https://issues.apache.org/jira/browse/CASSANDRA-14160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17433379#comment-17433379 ] Kanthi Subramanian commented on CASSANDRA-14160: [~e.dimitrova], [~brandon.williams] is this issue still valid, would be a good experience to work on SSTables. > maxPurgeableTimestamp should traverse tables in order of minTimestamp > - > > Key: CASSANDRA-14160 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14160 > Project: Cassandra > Issue Type: Bug > Components: Local/Compaction >Reporter: Josh Snyder >Priority: Normal > Labels: performance > Fix For: 4.x > > > In maxPurgeableTimestamp, we iterate over the bloom filters of each > overlapping SSTable. Of the bloom filter hits, we take the SSTable with the > lowest minTimestamp. If we kept the SSTables in sorted order of minTimestamp, > then we could short-circuit the operation at the first bloom filter hit, > reducing cache pressure (or worse, I/O) and CPU time. > I've written (but not yet benchmarked) [some > code|https://github.com/hashbrowncipher/cassandra/commit/29859a4a2e617f6775be49448858bc59fdafab44] > to demonstrate this possibility. -- 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-16751) Static column added in compact tables through Cassandra-stress tool
[
https://issues.apache.org/jira/browse/CASSANDRA-16751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kanthi Subramanian updated CASSANDRA-16751:
---
Resolution: Not A Problem
Status: Resolved (was: Open)
This is not a bug, maybe because the tool is not documented properly.
> Static column added in compact tables through Cassandra-stress tool
> ---
>
> Key: CASSANDRA-16751
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16751
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/stress
>Reporter: Radha
>Assignee: Kanthi Subramanian
>Priority: Normal
>
> I have Cassandra 3.11.9 installed on my setup. I used the Cassandra-stress
> tool to create data for my cluster.
> # cassandra-stress write n=800 -log file=/tmp/1 level=verbose -mode native
> cql3 user=cassandra password=cassandra -node nodeip
> I saw that two tables were created "counter1 and standard1".
> The "counter1" table had no data and also was created with the following
> configuration:
> cassandra@cqlsh> desc table keyspace1.counter1;
> cassandra@cqlsh> CREATE TABLE keyspace1.counter1 (
> key blob,
> column1 text,
> *"C0" counter static,*
> *"C1" counter static,*
> *"C2" counter static,*
> *"C3" counter static,*
> *"C4" counter static,*
> value counter,
> PRIMARY KEY (key, column1)
> ) *WITH COMPACT STORAGE*
> AND CLUSTERING ORDER BY (column1 ASC)
> AND bloom_filter_fp_chance = 0.01
> AND caching = \{'keys': 'ALL', 'rows_per_partition': 'NONE'}
> AND comment = ''
> AND compaction = {'class':
> 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy',
> 'max_threshold': '32', 'min_threshold': '4'}
> AND compression = \{'enabled': 'false'}
> AND crc_check_chance = 1.0
> AND dclocal_read_repair_chance = 0.1
> AND default_time_to_live = 0
> AND gc_grace_seconds = 864000
> AND max_index_interval = 2048
> AND memtable_flush_period_in_ms = 0
> AND min_index_interval = 128
> AND read_repair_chance = 0.0
> AND speculative_retry = '99PERCENTILE';
> Now if I try to create a similar schema manually with above-mentioned
> schema, I get the following error. InvalidRequest: Error from server:
> code=2200 [Invalid query] message="Static columns are not supported in
> COMPACT STORAGE tables"
>
> I further read more about this error and found that static columns cannot
> be used with COMPACT STORAGE tables.
> Here is the documentation for the same :
> 1.
> https://docs.datastax.com/en/cql-oss/3.3/cql/cql_using/useCompactStorage.html
> 2. https://programmersought.com/article/81431553936/
>
> I raised the same on dev as well as user Cassandra forum. I have got a reply
> from Benjamin Lerer that this is a bug and hence raising the JIRA.
> *Query details:*
> https://lists.apache.org/thread.html/rf9c74e8e3d431ff395f73677a616a9fcd70a46f3ea0500b71ca4d91d%40%3Cdev.cassandra.apache.org%3E
--
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] [Comment Edited] (CASSANDRA-16751) Static column added in compact tables through Cassandra-stress tool
[
https://issues.apache.org/jira/browse/CASSANDRA-16751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17433377#comment-17433377
]
Kanthi Subramanian edited comment on CASSANDRA-16751 at 10/23/21, 10:42 PM:
[~brandon.williams] ,Maybe this was fixed recently, counter1 table does not
have static columns. And when the command is COUNTER_ADD , the counter table
does have records.
select count from counter1;
count
---
800
describe table counter1;
CREATE TABLE keyspace1.counter1 (
key blob PRIMARY KEY,
*"C0" counter,*
*"C1" counter,*
*"C2" counter,*
*"C3" counter,*
*"C4" counter*
*) WITH additiona*l_write_policy = '99p'
AND bloom_filter_fp_chance = 0.01
AND caching = \{'keys': 'ALL', 'rows_per_partition': 'NONE'}
AND cdc = false
AND comment = ''
AND compaction = \{'class':
'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy',
'max_threshold': '32', 'min_threshold': '4'}
AND compression = \{'enabled': 'false'}
AND crc_check_chance = 1.0
AND default_time_to_live = 0
AND extensions = {}
AND gc_grace_seconds = 864000
AND max_index_interval = 2048
AND memtable_flush_period_in_ms = 0
AND min_index_interval = 128
AND read_repair = 'BLOCKING'
AND speculative_retry = '99p';
was (Author: subkanthi):
Maybe this was fixed recently, counter1 table does not have static columns. And
when the command is COUNTER_ADD , the counter table does have records.
select count(*) from counter1;
count
---
800
describe table counter1;
CREATE TABLE keyspace1.counter1 (
key blob PRIMARY KEY,
*"C0" counter,*
*"C1" counter,*
*"C2" counter,*
*"C3" counter,*
*"C4" counter*
*) WITH additiona*l_write_policy = '99p'
AND bloom_filter_fp_chance = 0.01
AND caching = \{'keys': 'ALL', 'rows_per_partition': 'NONE'}
AND cdc = false
AND comment = ''
AND compaction = \{'class':
'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy',
'max_threshold': '32', 'min_threshold': '4'}
AND compression = \{'enabled': 'false'}
AND crc_check_chance = 1.0
AND default_time_to_live = 0
AND extensions = {}
AND gc_grace_seconds = 864000
AND max_index_interval = 2048
AND memtable_flush_period_in_ms = 0
AND min_index_interval = 128
AND read_repair = 'BLOCKING'
AND speculative_retry = '99p';
> Static column added in compact tables through Cassandra-stress tool
> ---
>
> Key: CASSANDRA-16751
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16751
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/stress
>Reporter: Radha
>Assignee: Kanthi Subramanian
>Priority: Normal
>
> I have Cassandra 3.11.9 installed on my setup. I used the Cassandra-stress
> tool to create data for my cluster.
> # cassandra-stress write n=800 -log file=/tmp/1 level=verbose -mode native
> cql3 user=cassandra password=cassandra -node nodeip
> I saw that two tables were created "counter1 and standard1".
> The "counter1" table had no data and also was created with the following
> configuration:
> cassandra@cqlsh> desc table keyspace1.counter1;
> cassandra@cqlsh> CREATE TABLE keyspace1.counter1 (
> key blob,
> column1 text,
> *"C0" counter static,*
> *"C1" counter static,*
> *"C2" counter static,*
> *"C3" counter static,*
> *"C4" counter static,*
> value counter,
> PRIMARY KEY (key, column1)
> ) *WITH COMPACT STORAGE*
> AND CLUSTERING ORDER BY (column1 ASC)
> AND bloom_filter_fp_chance = 0.01
> AND caching = \{'keys': 'ALL', 'rows_per_partition': 'NONE'}
> AND comment = ''
> AND compaction = {'class':
> 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy',
> 'max_threshold': '32', 'min_threshold': '4'}
> AND compression = \{'enabled': 'false'}
> AND crc_check_chance = 1.0
> AND dclocal_read_repair_chance = 0.1
> AND default_time_to_live = 0
> AND gc_grace_seconds = 864000
> AND max_index_interval = 2048
> AND memtable_flush_period_in_ms = 0
> AND min_index_interval = 128
> AND read_repair_chance = 0.0
> AND speculative_retry = '99PERCENTILE';
> Now if I try to create a similar schema manually with above-mentioned
> schema, I get the following error. InvalidRequest: Error from server:
> code=2200 [Invalid query] message="Static columns are not supported in
> COMPACT STORAGE tables"
>
> I further read more about this error and found that static columns cannot
> be used with COMPACT STORAGE tables.
> Here is the documentation for the same :
> 1.
> https://docs.datastax.com/en/cql-oss/3.3/cql/cql_using/useCompactStorage.html
> 2. https://programmersought.com/article/81431553936/
>
> I raised the same on dev as well as user Cassandra forum. I have got a reply
> from Benjamin Lerer that this is a bug and hence raising the JIRA.
> *Query details:*
>
[jira] [Comment Edited] (CASSANDRA-16751) Static column added in compact tables through Cassandra-stress tool
[
https://issues.apache.org/jira/browse/CASSANDRA-16751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17433377#comment-17433377
]
Kanthi Subramanian edited comment on CASSANDRA-16751 at 10/23/21, 10:42 PM:
Maybe this was fixed recently, counter1 table does not have static columns. And
when the command is COUNTER_ADD , the counter table does have records.
select count(*) from counter1;
count
---
800
describe table counter1;
CREATE TABLE keyspace1.counter1 (
key blob PRIMARY KEY,
*"C0" counter,*
*"C1" counter,*
*"C2" counter,*
*"C3" counter,*
*"C4" counter*
*) WITH additiona*l_write_policy = '99p'
AND bloom_filter_fp_chance = 0.01
AND caching = \{'keys': 'ALL', 'rows_per_partition': 'NONE'}
AND cdc = false
AND comment = ''
AND compaction = \{'class':
'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy',
'max_threshold': '32', 'min_threshold': '4'}
AND compression = \{'enabled': 'false'}
AND crc_check_chance = 1.0
AND default_time_to_live = 0
AND extensions = {}
AND gc_grace_seconds = 864000
AND max_index_interval = 2048
AND memtable_flush_period_in_ms = 0
AND min_index_interval = 128
AND read_repair = 'BLOCKING'
AND speculative_retry = '99p';
was (Author: subkanthi):
describe table counter1;
CREATE TABLE keyspace1.counter1 (
key blob PRIMARY KEY,
*"C0" counter,*
*"C1" counter,*
*"C2" counter,*
*"C3" counter,*
*"C4" counter*
*) WITH additiona*l_write_policy = '99p'
AND bloom_filter_fp_chance = 0.01
AND caching = \{'keys': 'ALL', 'rows_per_partition': 'NONE'}
AND cdc = false
AND comment = ''
AND compaction = \{'class':
'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy',
'max_threshold': '32', 'min_threshold': '4'}
AND compression = \{'enabled': 'false'}
AND crc_check_chance = 1.0
AND default_time_to_live = 0
AND extensions = {}
AND gc_grace_seconds = 864000
AND max_index_interval = 2048
AND memtable_flush_period_in_ms = 0
AND min_index_interval = 128
AND read_repair = 'BLOCKING'
AND speculative_retry = '99p';
> Static column added in compact tables through Cassandra-stress tool
> ---
>
> Key: CASSANDRA-16751
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16751
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/stress
>Reporter: Radha
>Assignee: Kanthi Subramanian
>Priority: Normal
>
> I have Cassandra 3.11.9 installed on my setup. I used the Cassandra-stress
> tool to create data for my cluster.
> # cassandra-stress write n=800 -log file=/tmp/1 level=verbose -mode native
> cql3 user=cassandra password=cassandra -node nodeip
> I saw that two tables were created "counter1 and standard1".
> The "counter1" table had no data and also was created with the following
> configuration:
> cassandra@cqlsh> desc table keyspace1.counter1;
> cassandra@cqlsh> CREATE TABLE keyspace1.counter1 (
> key blob,
> column1 text,
> *"C0" counter static,*
> *"C1" counter static,*
> *"C2" counter static,*
> *"C3" counter static,*
> *"C4" counter static,*
> value counter,
> PRIMARY KEY (key, column1)
> ) *WITH COMPACT STORAGE*
> AND CLUSTERING ORDER BY (column1 ASC)
> AND bloom_filter_fp_chance = 0.01
> AND caching = \{'keys': 'ALL', 'rows_per_partition': 'NONE'}
> AND comment = ''
> AND compaction = {'class':
> 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy',
> 'max_threshold': '32', 'min_threshold': '4'}
> AND compression = \{'enabled': 'false'}
> AND crc_check_chance = 1.0
> AND dclocal_read_repair_chance = 0.1
> AND default_time_to_live = 0
> AND gc_grace_seconds = 864000
> AND max_index_interval = 2048
> AND memtable_flush_period_in_ms = 0
> AND min_index_interval = 128
> AND read_repair_chance = 0.0
> AND speculative_retry = '99PERCENTILE';
> Now if I try to create a similar schema manually with above-mentioned
> schema, I get the following error. InvalidRequest: Error from server:
> code=2200 [Invalid query] message="Static columns are not supported in
> COMPACT STORAGE tables"
>
> I further read more about this error and found that static columns cannot
> be used with COMPACT STORAGE tables.
> Here is the documentation for the same :
> 1.
> https://docs.datastax.com/en/cql-oss/3.3/cql/cql_using/useCompactStorage.html
> 2. https://programmersought.com/article/81431553936/
>
> I raised the same on dev as well as user Cassandra forum. I have got a reply
> from Benjamin Lerer that this is a bug and hence raising the JIRA.
> *Query details:*
> https://lists.apache.org/thread.html/rf9c74e8e3d431ff395f73677a616a9fcd70a46f3ea0500b71ca4d91d%40%3Cdev.cassandra.apache.org%3E
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe,
[jira] [Commented] (CASSANDRA-16751) Static column added in compact tables through Cassandra-stress tool
[
https://issues.apache.org/jira/browse/CASSANDRA-16751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17433377#comment-17433377
]
Kanthi Subramanian commented on CASSANDRA-16751:
describe table counter1;
CREATE TABLE keyspace1.counter1 (
key blob PRIMARY KEY,
*"C0" counter,*
*"C1" counter,*
*"C2" counter,*
*"C3" counter,*
*"C4" counter*
*) WITH additiona*l_write_policy = '99p'
AND bloom_filter_fp_chance = 0.01
AND caching = \{'keys': 'ALL', 'rows_per_partition': 'NONE'}
AND cdc = false
AND comment = ''
AND compaction = \{'class':
'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy',
'max_threshold': '32', 'min_threshold': '4'}
AND compression = \{'enabled': 'false'}
AND crc_check_chance = 1.0
AND default_time_to_live = 0
AND extensions = {}
AND gc_grace_seconds = 864000
AND max_index_interval = 2048
AND memtable_flush_period_in_ms = 0
AND min_index_interval = 128
AND read_repair = 'BLOCKING'
AND speculative_retry = '99p';
> Static column added in compact tables through Cassandra-stress tool
> ---
>
> Key: CASSANDRA-16751
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16751
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/stress
>Reporter: Radha
>Assignee: Kanthi Subramanian
>Priority: Normal
>
> I have Cassandra 3.11.9 installed on my setup. I used the Cassandra-stress
> tool to create data for my cluster.
> # cassandra-stress write n=800 -log file=/tmp/1 level=verbose -mode native
> cql3 user=cassandra password=cassandra -node nodeip
> I saw that two tables were created "counter1 and standard1".
> The "counter1" table had no data and also was created with the following
> configuration:
> cassandra@cqlsh> desc table keyspace1.counter1;
> cassandra@cqlsh> CREATE TABLE keyspace1.counter1 (
> key blob,
> column1 text,
> *"C0" counter static,*
> *"C1" counter static,*
> *"C2" counter static,*
> *"C3" counter static,*
> *"C4" counter static,*
> value counter,
> PRIMARY KEY (key, column1)
> ) *WITH COMPACT STORAGE*
> AND CLUSTERING ORDER BY (column1 ASC)
> AND bloom_filter_fp_chance = 0.01
> AND caching = \{'keys': 'ALL', 'rows_per_partition': 'NONE'}
> AND comment = ''
> AND compaction = {'class':
> 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy',
> 'max_threshold': '32', 'min_threshold': '4'}
> AND compression = \{'enabled': 'false'}
> AND crc_check_chance = 1.0
> AND dclocal_read_repair_chance = 0.1
> AND default_time_to_live = 0
> AND gc_grace_seconds = 864000
> AND max_index_interval = 2048
> AND memtable_flush_period_in_ms = 0
> AND min_index_interval = 128
> AND read_repair_chance = 0.0
> AND speculative_retry = '99PERCENTILE';
> Now if I try to create a similar schema manually with above-mentioned
> schema, I get the following error. InvalidRequest: Error from server:
> code=2200 [Invalid query] message="Static columns are not supported in
> COMPACT STORAGE tables"
>
> I further read more about this error and found that static columns cannot
> be used with COMPACT STORAGE tables.
> Here is the documentation for the same :
> 1.
> https://docs.datastax.com/en/cql-oss/3.3/cql/cql_using/useCompactStorage.html
> 2. https://programmersought.com/article/81431553936/
>
> I raised the same on dev as well as user Cassandra forum. I have got a reply
> from Benjamin Lerer that this is a bug and hence raising the JIRA.
> *Query details:*
> https://lists.apache.org/thread.html/rf9c74e8e3d431ff395f73677a616a9fcd70a46f3ea0500b71ca4d91d%40%3Cdev.cassandra.apache.org%3E
--
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=17433113#comment-17433113
]
Kanthi Subramanian commented on CASSANDRA-17029:
Sorry Im fairly new, should I be monitoring the circle-ci tests, please let me
know.
> 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] [Assigned] (CASSANDRA-16751) Static column added in compact tables through Cassandra-stress tool
[
https://issues.apache.org/jira/browse/CASSANDRA-16751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kanthi Subramanian reassigned CASSANDRA-16751:
--
Assignee: Kanthi Subramanian
> Static column added in compact tables through Cassandra-stress tool
> ---
>
> Key: CASSANDRA-16751
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16751
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/stress
>Reporter: Radha
>Assignee: Kanthi Subramanian
>Priority: Normal
>
> I have Cassandra 3.11.9 installed on my setup. I used the Cassandra-stress
> tool to create data for my cluster.
> # cassandra-stress write n=800 -log file=/tmp/1 level=verbose -mode native
> cql3 user=cassandra password=cassandra -node nodeip
> I saw that two tables were created "counter1 and standard1".
> The "counter1" table had no data and also was created with the following
> configuration:
> cassandra@cqlsh> desc table keyspace1.counter1;
> cassandra@cqlsh> CREATE TABLE keyspace1.counter1 (
> key blob,
> column1 text,
> *"C0" counter static,*
> *"C1" counter static,*
> *"C2" counter static,*
> *"C3" counter static,*
> *"C4" counter static,*
> value counter,
> PRIMARY KEY (key, column1)
> ) *WITH COMPACT STORAGE*
> AND CLUSTERING ORDER BY (column1 ASC)
> AND bloom_filter_fp_chance = 0.01
> AND caching = \{'keys': 'ALL', 'rows_per_partition': 'NONE'}
> AND comment = ''
> AND compaction = {'class':
> 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy',
> 'max_threshold': '32', 'min_threshold': '4'}
> AND compression = \{'enabled': 'false'}
> AND crc_check_chance = 1.0
> AND dclocal_read_repair_chance = 0.1
> AND default_time_to_live = 0
> AND gc_grace_seconds = 864000
> AND max_index_interval = 2048
> AND memtable_flush_period_in_ms = 0
> AND min_index_interval = 128
> AND read_repair_chance = 0.0
> AND speculative_retry = '99PERCENTILE';
> Now if I try to create a similar schema manually with above-mentioned
> schema, I get the following error. InvalidRequest: Error from server:
> code=2200 [Invalid query] message="Static columns are not supported in
> COMPACT STORAGE tables"
>
> I further read more about this error and found that static columns cannot
> be used with COMPACT STORAGE tables.
> Here is the documentation for the same :
> 1.
> https://docs.datastax.com/en/cql-oss/3.3/cql/cql_using/useCompactStorage.html
> 2. https://programmersought.com/article/81431553936/
>
> I raised the same on dev as well as user Cassandra forum. I have got a reply
> from Benjamin Lerer that this is a bug and hence raising the JIRA.
> *Query details:*
> https://lists.apache.org/thread.html/rf9c74e8e3d431ff395f73677a616a9fcd70a46f3ea0500b71ca4d91d%40%3Cdev.cassandra.apache.org%3E
--
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-17029) Add unix time conversion functions
[
https://issues.apache.org/jira/browse/CASSANDRA-17029?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kanthi Subramanian updated CASSANDRA-17029:
---
Test and Documentation Plan: https://github.com/apache/cassandra/pull/1275
Status: Patch Available (was: 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] [Updated] (CASSANDRA-17023) Eliminate toCQLString() duplication between ReadCommand and AbstractReadQuery
[
https://issues.apache.org/jira/browse/CASSANDRA-17023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kanthi Subramanian updated CASSANDRA-17023:
---
Test and Documentation Plan:
https://github.com/apache/cassandra/pull/1282/files
Status: Patch Available (was: In Progress)
> Eliminate toCQLString() duplication between ReadCommand and AbstractReadQuery
> -
>
> Key: CASSANDRA-17023
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17023
> Project: Cassandra
> Issue Type: Task
> Components: CQL/Syntax
>Reporter: Caleb Rackliffe
>Assignee: Kanthi Subramanian
>Priority: Normal
> Fix For: 4.1
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> This is certainly low-hanging fruit, but the {{toCQLString()}} in
> {{ReadCommand}} now entirely duplicates the one in its superclass
> {{AbstractReadQuery}}. I think we can just remove the former.
--
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] [Assigned] (CASSANDRA-9430) Add startup options to cqlshrc
[
https://issues.apache.org/jira/browse/CASSANDRA-9430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kanthi Subramanian reassigned CASSANDRA-9430:
-
Assignee: Kanthi Subramanian
> Add startup options to cqlshrc
> --
>
> Key: CASSANDRA-9430
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9430
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Tools
>Reporter: Jeremy Hanna
>Assignee: Kanthi Subramanian
>Priority: Low
> Labels: cqlsh, lhf
>
> There are certain settings that would be nice to set defaults for in the
> cqlshrc file. For example, a user may want to set the paging to off by
> default for their environment. You can't simply do
> {code}
> echo "paging off;" | cqlsh
> {code}
> because this would disable paging and immediately exit cqlsh.
> So it would be nice to have a section of the cqlshrc to include default
> settings on startup.
--
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-9430) Add startup options to cqlshrc
[
https://issues.apache.org/jira/browse/CASSANDRA-9430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17432593#comment-17432593
]
Kanthi Subramanian commented on CASSANDRA-9430:
---
[~brandon.williams] is this still applicable, I can use the original patch.
> Add startup options to cqlshrc
> --
>
> Key: CASSANDRA-9430
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9430
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Tools
>Reporter: Jeremy Hanna
>Priority: Low
> Labels: cqlsh, lhf
>
> There are certain settings that would be nice to set defaults for in the
> cqlshrc file. For example, a user may want to set the paging to off by
> default for their environment. You can't simply do
> {code}
> echo "paging off;" | cqlsh
> {code}
> because this would disable paging and immediately exit cqlsh.
> So it would be nice to have a section of the cqlshrc to include default
> settings on startup.
--
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] [Assigned] (CASSANDRA-17023) Eliminate toCQLString() duplication between ReadCommand and AbstractReadQuery
[
https://issues.apache.org/jira/browse/CASSANDRA-17023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kanthi Subramanian reassigned CASSANDRA-17023:
--
Assignee: Kanthi Subramanian
> Eliminate toCQLString() duplication between ReadCommand and AbstractReadQuery
> -
>
> Key: CASSANDRA-17023
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17023
> Project: Cassandra
> Issue Type: Task
> Components: CQL/Syntax
>Reporter: Caleb Rackliffe
>Assignee: Kanthi Subramanian
>Priority: Normal
> Fix For: 4.1
>
>
> This is certainly low-hanging fruit, but the {{toCQLString()}} in
> {{ReadCommand}} now entirely duplicates the one in its superclass
> {{AbstractReadQuery}}. I think we can just remove the former.
--
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-16903) UDTs named after built-in data types
[
https://issues.apache.org/jira/browse/CASSANDRA-16903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17432121#comment-17432121
]
Kanthi Subramanian commented on CASSANDRA-16903:
[~blerer], can the logic be implemented in this function or is it in the ANTLR
parser. I was trying to figure out the parser.g (not an expert in antlr), just
couldnt figure out how the comparatorType only checks for native types.
Appreciate any help
{code:java}
// code placeholder
public Keyspaces apply(Keyspaces schema)
{
KeyspaceMetadata keyspace = schema.getNullable(keyspaceName);
if (null == keyspace)
throw ire("Keyspace '%s' doesn't exist", keyspaceName);
UserType existingType = keyspace.types.getNullable(bytes(typeName));
if (null != existingType)
{
if (ifNotExists)
return schema;
throw ire("A user type with name '%s' already exists", typeName);
}
Set usedNames = new HashSet<>();
for (FieldIdentifier name : fieldNames)
if (!usedNames.add(name))
throw ire("Duplicate field name '%s' in type '%s'", name, typeName);
for (CQL3Type.Raw type : rawFieldTypes)
{
if (type.isCounter())
throw ire("A user type cannot contain counters");
if (type.isUDT() && !type.isFrozen())
throw ire("A user type cannot contain non-frozen UDTs");
}
List> fieldTypes =
rawFieldTypes.stream()
.map(t -> t.prepare(keyspaceName,
keyspace.types).getType())
.collect(toList());
UserType udt = new UserType(keyspaceName, bytes(typeName), fieldNames,
fieldTypes, true);
return
schema.withAddedOrUpdated(keyspace.withSwapped(keyspace.types.with(udt)));
}
{code}
> UDTs named after built-in data types
>
>
> Key: CASSANDRA-16903
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16903
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/UDT
>Reporter: Brandon Bordeaux
>Assignee: Kanthi Subramanian
>Priority: Normal
> Fix For: 4.0.x
>
>
> Working with Cassandra 4.0 I found UDTs can be named after some built-in data
> type, like map, list, and tuple, but not for other types, like text or set.
> This behavior should be consistent across all built-in types where Cassandra
> shouldn't allow a UDT to be named after any built-in type.
> Having UDTs named after built-in types cause confusion working with table
> schemas and may introduce downstream issues when Cassandra works with these
> types.
--
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] [Assigned] (CASSANDRA-16903) UDTs named after built-in data types
[ https://issues.apache.org/jira/browse/CASSANDRA-16903?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kanthi Subramanian reassigned CASSANDRA-16903: -- Assignee: Kanthi Subramanian > UDTs named after built-in data types > > > Key: CASSANDRA-16903 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16903 > Project: Cassandra > Issue Type: Bug > Components: Feature/UDT >Reporter: Brandon Bordeaux >Assignee: Kanthi Subramanian >Priority: Normal > Fix For: 4.0.x > > > Working with Cassandra 4.0 I found UDTs can be named after some built-in data > type, like map, list, and tuple, but not for other types, like text or set. > This behavior should be consistent across all built-in types where Cassandra > shouldn't allow a UDT to be named after any built-in type. > Having UDTs named after built-in types cause confusion working with table > schemas and may introduce downstream issues when Cassandra works with these > types. -- 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] [Assigned] (CASSANDRA-16903) UDTs named after built-in data types
[ https://issues.apache.org/jira/browse/CASSANDRA-16903?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kanthi Subramanian reassigned CASSANDRA-16903: -- Assignee: (was: Kanthi Subramanian) > UDTs named after built-in data types > > > Key: CASSANDRA-16903 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16903 > Project: Cassandra > Issue Type: Bug > Components: Feature/UDT >Reporter: Brandon Bordeaux >Priority: Normal > Fix For: 4.0.x > > > Working with Cassandra 4.0 I found UDTs can be named after some built-in data > type, like map, list, and tuple, but not for other types, like text or set. > This behavior should be consistent across all built-in types where Cassandra > shouldn't allow a UDT to be named after any built-in type. > Having UDTs named after built-in types cause confusion working with table > schemas and may introduce downstream issues when Cassandra works with these > types. -- 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] [Assigned] (CASSANDRA-16903) UDTs named after built-in data types
[ https://issues.apache.org/jira/browse/CASSANDRA-16903?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kanthi Subramanian reassigned CASSANDRA-16903: -- Assignee: Kanthi Subramanian > UDTs named after built-in data types > > > Key: CASSANDRA-16903 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16903 > Project: Cassandra > Issue Type: Bug > Components: Feature/UDT >Reporter: Brandon Bordeaux >Assignee: Kanthi Subramanian >Priority: Normal > Fix For: 4.0.x > > > Working with Cassandra 4.0 I found UDTs can be named after some built-in data > type, like map, list, and tuple, but not for other types, like text or set. > This behavior should be consistent across all built-in types where Cassandra > shouldn't allow a UDT to be named after any built-in type. > Having UDTs named after built-in types cause confusion working with table > schemas and may introduce downstream issues when Cassandra works with these > types. -- 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-16903) UDTs named after built-in data types
[ https://issues.apache.org/jira/browse/CASSANDRA-16903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17430839#comment-17430839 ] Kanthi Subramanian commented on CASSANDRA-16903: is this something I can take on, UDTs disallowing map and set > UDTs named after built-in data types > > > Key: CASSANDRA-16903 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16903 > Project: Cassandra > Issue Type: Bug > Components: Feature/UDT >Reporter: Brandon Bordeaux >Priority: Normal > Fix For: 4.0.x > > > Working with Cassandra 4.0 I found UDTs can be named after some built-in data > type, like map, list, and tuple, but not for other types, like text or set. > This behavior should be consistent across all built-in types where Cassandra > shouldn't allow a UDT to be named after any built-in type. > Having UDTs named after built-in types cause confusion working with table > schemas and may introduce downstream issues when Cassandra works with these > types. -- 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=17429787#comment-17429787
]
Kanthi Subramanian commented on CASSANDRA-17029:
[https://github.com/apache/cassandra/pull/1275]
Apologize, I know its a simple task, but [~brandon.williams] or [~blerer], can
you please check if Im on the right direction, will change all the functions.
> 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=17428877#comment-17428877
]
Kanthi Subramanian commented on CASSANDRA-17029:
Thanks Brandon, unfortunately I dont have an apache email address, I have sent
you an email to dri...@gmail.com, please send the invite
> 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=17428868#comment-17428868
]
Kanthi Subramanian commented on CASSANDRA-17029:
[~blerer], there are functions for toDate which takes in the TemporalType,
trying to understand TemporalTypes, is BigInteger not included in TemporalType?
Also is there a process to get included in the slack channel, Im kind of used
to asking questions in slack for Airflow.
> 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] [Comment Edited] (CASSANDRA-17029) Add unix time conversion functions
[
https://issues.apache.org/jira/browse/CASSANDRA-17029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17426454#comment-17426454
]
Kanthi Subramanian edited comment on CASSANDRA-17029 at 10/9/21, 3:13 AM:
--
Hi [~blerer], is it OK to create PRs in github
[https://github.com/apache/cassandra] against the trunk branch, confused
because I see some documentation referring to patches.
Thanks in advance.
was (Author: subkanthi):
Hi [~blerer], is it OK to create PRs in github
[https://github.com/apache/cassandra] against the trunk branch, confused
because I see some documentation referring to patches.
> 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=17426454#comment-17426454
]
Kanthi Subramanian commented on CASSANDRA-17029:
Hi [~blerer], is it OK to create PRs in github
[https://github.com/apache/cassandra] against the trunk branch, confused
because I see some documentation referring to patches.
> 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] [Assigned] (CASSANDRA-17029) Add unix time conversion functions
[
https://issues.apache.org/jira/browse/CASSANDRA-17029?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kanthi Subramanian reassigned CASSANDRA-17029:
--
Assignee: Kanthi Subramanian
> 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] [Comment Edited] (CASSANDRA-17029) Add unix time conversion functions
[
https://issues.apache.org/jira/browse/CASSANDRA-17029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17426260#comment-17426260
]
Kanthi Subramanian edited comment on CASSANDRA-17029 at 10/8/21, 4:15 PM:
--
Thanks [~blerer], really appreciate it, will check the info and when Im
confident, will assign it to myself.
was (Author: subkanthi):
Thanks [~blerer], really appreciate it, will check the info and when Im
confident, will assign it myself.
> 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
>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=17426260#comment-17426260
]
Kanthi Subramanian commented on CASSANDRA-17029:
Thanks [~blerer], really appreciate it, will check the info and when Im
confident, will assign it myself.
> 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
>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-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=17424757#comment-17424757
]
Kanthi Subramanian commented on CASSANDRA-16916:
[~blerer] Is this being worked on? also hunting for low -hanging fruits,
appreciate if you can point me to other tickets. Thanks in advance
> 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.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
