[jira] [Comment Edited] (CASSANDRA-18879) Modernize CQLSH datetime conversions
[
https://issues.apache.org/jira/browse/CASSANDRA-18879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17797402#comment-17797402
]
Arun Ganesh edited comment on CASSANDRA-18879 at 12/16/23 11:10 AM:
[~bschoeni], sorry for the long delay.
I did some study on the datetime functions today. Apparently, PEP 495 doesn't
introduce new functions; it just modifies the behavior of the existing API.
This doesn't have any direct effect on our code, apart from how the internal
datetime objects are handled by the API functions. So, we don't have anything
to do with regards to PEP 495.
However, I did notice an issue with the {{datetime_from_utc_to_local}}
function. Because of how it converts UTC to local time, it seems that it cannot
handle daylight savings and timezones that have had different UTC offsets in
the past (see comments under [https://stackoverflow.com/a/19238551/9523462).]
We can fix it using {{{}astimezone(){}}}. However, it works as expected only
when you run it on "aware" datetime objects. Aware datetime objects know about
their timezone. The datetime objects that we obtain from the driver are "naive"
(see
[https://docs.datastax.com/en/developer/python-driver/3.28/dates_and_times/#read-path)].
To properly convert them to local time, we need to make them "aware" by
calling {{replace()}} before calling the {{{}astimezone(){}}}. So, we still
need to keep {{datetime_from_utc_to_local}} and just modify it.
I've raised a [draft PR|https://github.com/apache/cassandra/pull/2996] with
these changes. All pytests pass for me (2 tests failed on the clean trunk). Let
me know what you think of it when you find time. Will it help if I added some
unit tests?
Thanks,
Arun
was (Author: JIRAUSER303038):
[~bschoeni], sorry for the long delay.
I did some study on the datetime functions today. Apparently, PEP 495 doesn't
introduce new functions; it just modifies the behavior of the existing API.
This doesn't have any direct effect on our code, apart from how the internal
datetime objects are handled by the API functions. So, we don't have anything
to do with regards to PEP 495.
However, I did notice an issue with the `datetime_from_utc_to_local` function.
Because of how it converts UTC to local time, it seems that it cannot handle
daylight savings and timezones that have had different UTC offsets in the past
(see comments under [https://stackoverflow.com/a/19238551/9523462).] We can fix
it using `astimezone()`. However, it works as expected only when you run it on
"aware" datetime objects. Aware datetime objects know about their timezone. The
datetime objects that we obtain from the driver are "naive" (see
[https://docs.datastax.com/en/developer/python-driver/3.28/dates_and_times/#read-path)].
To properly convert them to local time, we need to make them "aware" by
calling `replace()` before calling the `astimezone()`. So, we still need to
keep `datetime_from_utc_to_local` and just modify it.
I've raised a [draft PR|https://github.com/apache/cassandra/pull/2996] with
these changes. All pytests passed (2 tests failed on the clean trunk). Let me
know what you think of it when you find time. Will it help to add unit tests?
Thanks,
Arun
> Modernize CQLSH datetime conversions
>
>
> Key: CASSANDRA-18879
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18879
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Brad Schoening
>Assignee: Arun Ganesh
>Priority: Low
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Python 3.x introduced many updates to datetime conversion which allows
> simplified conversions.
> 1. For example, tracing.py defines a function datetime_from_utc_to_local()
> but datetime now has a native function astimezone() which will convert UTC to
> local time.
> Review the following users of datetime which apply conversions:
> * cqlshmain.py
> * formatting.py
> * tracing.py
> Example:
> {code:java}
> >>> a = datetime.datetime.now().astimezone(tz.tzutc())
> >>> a
> datetime.datetime(2023, 9, 25, 11, 22, 36, 251705, tzinfo=tzutc())
> >>> b = a.astimezone()
> >>> b
> datetime.datetime(2023, 9, 25, 14, 22, 36, 251705,
> tzinfo=datetime.timezone(datetime.timedelta(seconds=10800), 'EEST')) {code}
> See [PEP 495|https://peps.python.org/pep-0495/]
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18879) Modernize CQLSH datetime conversions
[
https://issues.apache.org/jira/browse/CASSANDRA-18879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17797402#comment-17797402
]
Arun Ganesh edited comment on CASSANDRA-18879 at 12/16/23 11:10 AM:
[~bschoeni], sorry for the long delay.
I did some study on the datetime functions today. Apparently, PEP 495 doesn't
introduce new functions; it just modifies the behavior of the existing API.
This doesn't have any direct effect on our code, apart from how the internal
datetime objects are handled by the API functions. So, we don't have anything
to do with regard to PEP 495.
However, I did notice an issue with the {{datetime_from_utc_to_local}}
function. Because of how it converts UTC to local time, it seems that it cannot
handle daylight savings and timezones that have had different UTC offsets in
the past (see comments under [https://stackoverflow.com/a/19238551/9523462).]
We can fix it using {{{}astimezone(){}}}. However, it works as expected only
when you run it on "aware" datetime objects. Aware datetime objects know about
their timezone. The datetime objects that we obtain from the driver are "naive"
(see
[https://docs.datastax.com/en/developer/python-driver/3.28/dates_and_times/#read-path)].
To properly convert them to local time, we need to make them "aware" by
calling {{replace()}} before calling the {{{}astimezone(){}}}. So, we still
need to keep {{datetime_from_utc_to_local}} and just modify it.
I've raised a [draft PR|https://github.com/apache/cassandra/pull/2996] with
these changes. All pytests pass for me (2 tests failed on the clean trunk). Let
me know what you think of it when you find time. Will it help if I added some
unit tests?
Thanks,
Arun
was (Author: JIRAUSER303038):
[~bschoeni], sorry for the long delay.
I did some study on the datetime functions today. Apparently, PEP 495 doesn't
introduce new functions; it just modifies the behavior of the existing API.
This doesn't have any direct effect on our code, apart from how the internal
datetime objects are handled by the API functions. So, we don't have anything
to do with regards to PEP 495.
However, I did notice an issue with the {{datetime_from_utc_to_local}}
function. Because of how it converts UTC to local time, it seems that it cannot
handle daylight savings and timezones that have had different UTC offsets in
the past (see comments under [https://stackoverflow.com/a/19238551/9523462).]
We can fix it using {{{}astimezone(){}}}. However, it works as expected only
when you run it on "aware" datetime objects. Aware datetime objects know about
their timezone. The datetime objects that we obtain from the driver are "naive"
(see
[https://docs.datastax.com/en/developer/python-driver/3.28/dates_and_times/#read-path)].
To properly convert them to local time, we need to make them "aware" by
calling {{replace()}} before calling the {{{}astimezone(){}}}. So, we still
need to keep {{datetime_from_utc_to_local}} and just modify it.
I've raised a [draft PR|https://github.com/apache/cassandra/pull/2996] with
these changes. All pytests pass for me (2 tests failed on the clean trunk). Let
me know what you think of it when you find time. Will it help if I added some
unit tests?
Thanks,
Arun
> Modernize CQLSH datetime conversions
>
>
> Key: CASSANDRA-18879
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18879
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Brad Schoening
>Assignee: Arun Ganesh
>Priority: Low
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Python 3.x introduced many updates to datetime conversion which allows
> simplified conversions.
> 1. For example, tracing.py defines a function datetime_from_utc_to_local()
> but datetime now has a native function astimezone() which will convert UTC to
> local time.
> Review the following users of datetime which apply conversions:
> * cqlshmain.py
> * formatting.py
> * tracing.py
> Example:
> {code:java}
> >>> a = datetime.datetime.now().astimezone(tz.tzutc())
> >>> a
> datetime.datetime(2023, 9, 25, 11, 22, 36, 251705, tzinfo=tzutc())
> >>> b = a.astimezone()
> >>> b
> datetime.datetime(2023, 9, 25, 14, 22, 36, 251705,
> tzinfo=datetime.timezone(datetime.timedelta(seconds=10800), 'EEST')) {code}
> See [PEP 495|https://peps.python.org/pep-0495/]
>
--
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-18879) Modernize CQLSH datetime conversions
[
https://issues.apache.org/jira/browse/CASSANDRA-18879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17797402#comment-17797402
]
Arun Ganesh commented on CASSANDRA-18879:
-
[~bschoeni], sorry for the long delay.
I did some study on the datetime functions today. Apparently, PEP 495 doesn't
introduce new functions; it just modifies the behavior of the existing API.
This doesn't have any direct effect on our code, apart from how the internal
datetime objects are handled by the API functions. So, we don't have anything
to do with regards to PEP 495.
However, I did notice an issue with the `datetime_from_utc_to_local` function.
Because of how it converts UTC to local time, it seems that it cannot handle
daylight savings and timezones that have had different UTC offsets in the past
(see comments under [https://stackoverflow.com/a/19238551/9523462).] We can fix
it using `astimezone()`. However, it works as expected only when you run it on
"aware" datetime objects. Aware datetime objects know about their timezone. The
datetime objects that we obtain from the driver are "naive" (see
[https://docs.datastax.com/en/developer/python-driver/3.28/dates_and_times/#read-path)].
To properly convert them to local time, we need to make them "aware" by
calling `replace()` before calling the `astimezone()`. So, we still need to
keep `datetime_from_utc_to_local` and just modify it.
I've raised a [draft PR|https://github.com/apache/cassandra/pull/2996] with
these changes. All pytests passed (2 tests failed on the clean trunk). Let me
know what you think of it when you find time. Will it help to add unit tests?
Thanks,
Arun
> Modernize CQLSH datetime conversions
>
>
> Key: CASSANDRA-18879
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18879
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Brad Schoening
>Assignee: Arun Ganesh
>Priority: Low
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Python 3.x introduced many updates to datetime conversion which allows
> simplified conversions.
> 1. For example, tracing.py defines a function datetime_from_utc_to_local()
> but datetime now has a native function astimezone() which will convert UTC to
> local time.
> Review the following users of datetime which apply conversions:
> * cqlshmain.py
> * formatting.py
> * tracing.py
> Example:
> {code:java}
> >>> a = datetime.datetime.now().astimezone(tz.tzutc())
> >>> a
> datetime.datetime(2023, 9, 25, 11, 22, 36, 251705, tzinfo=tzutc())
> >>> b = a.astimezone()
> >>> b
> datetime.datetime(2023, 9, 25, 14, 22, 36, 251705,
> tzinfo=datetime.timezone(datetime.timedelta(seconds=10800), 'EEST')) {code}
> See [PEP 495|https://peps.python.org/pep-0495/]
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18879) Modernize CQLSH datetime conversions
[
https://issues.apache.org/jira/browse/CASSANDRA-18879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17797402#comment-17797402
]
Arun Ganesh edited comment on CASSANDRA-18879 at 12/16/23 11:12 AM:
[~bschoeni], sorry for the long delay.
I did some study on the datetime functions today. Apparently, PEP 495 doesn't
introduce new functions; it just modifies the behavior of the existing API.
This doesn't have any direct effect on our code, apart from how the internal
datetime objects are handled by the API functions. So, we don't have anything
to do regarding PEP 495.
However, I did notice an issue with the {{datetime_from_utc_to_local}}
function. Because of how it converts UTC to local time, it seems that it cannot
handle daylight savings and timezones that have had different UTC offsets in
the past (see comments under [https://stackoverflow.com/a/19238551/9523462).]
We can fix it using {{{}astimezone(){}}}. However, it works as expected only
when you run it on "aware" datetime objects. Aware datetime objects know about
their timezone. The datetime objects that we obtain from the driver are "naive"
(see
[https://docs.datastax.com/en/developer/python-driver/3.28/dates_and_times/#read-path)].
To properly convert them to local time, we need to make them "aware" by
calling {{replace()}} before calling the {{{}astimezone(){}}}. So, we still
need to keep {{datetime_from_utc_to_local}} and just modify it.
I've raised a [draft PR|https://github.com/apache/cassandra/pull/2996] with
these changes. All pytests pass for me (2 tests failed on the clean trunk). Let
me know what you think of it when you find time. Will it help if I added some
unit tests?
Thanks,
Arun
was (Author: JIRAUSER303038):
[~bschoeni], sorry for the long delay.
I did some study on the datetime functions today. Apparently, PEP 495 doesn't
introduce new functions; it just modifies the behavior of the existing API.
This doesn't have any direct effect on our code, apart from how the internal
datetime objects are handled by the API functions. So, we don't have anything
to do with regard to PEP 495.
However, I did notice an issue with the {{datetime_from_utc_to_local}}
function. Because of how it converts UTC to local time, it seems that it cannot
handle daylight savings and timezones that have had different UTC offsets in
the past (see comments under [https://stackoverflow.com/a/19238551/9523462).]
We can fix it using {{{}astimezone(){}}}. However, it works as expected only
when you run it on "aware" datetime objects. Aware datetime objects know about
their timezone. The datetime objects that we obtain from the driver are "naive"
(see
[https://docs.datastax.com/en/developer/python-driver/3.28/dates_and_times/#read-path)].
To properly convert them to local time, we need to make them "aware" by
calling {{replace()}} before calling the {{{}astimezone(){}}}. So, we still
need to keep {{datetime_from_utc_to_local}} and just modify it.
I've raised a [draft PR|https://github.com/apache/cassandra/pull/2996] with
these changes. All pytests pass for me (2 tests failed on the clean trunk). Let
me know what you think of it when you find time. Will it help if I added some
unit tests?
Thanks,
Arun
> Modernize CQLSH datetime conversions
>
>
> Key: CASSANDRA-18879
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18879
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Brad Schoening
>Assignee: Arun Ganesh
>Priority: Low
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Python 3.x introduced many updates to datetime conversion which allows
> simplified conversions.
> 1. For example, tracing.py defines a function datetime_from_utc_to_local()
> but datetime now has a native function astimezone() which will convert UTC to
> local time.
> Review the following users of datetime which apply conversions:
> * cqlshmain.py
> * formatting.py
> * tracing.py
> Example:
> {code:java}
> >>> a = datetime.datetime.now().astimezone(tz.tzutc())
> >>> a
> datetime.datetime(2023, 9, 25, 11, 22, 36, 251705, tzinfo=tzutc())
> >>> b = a.astimezone()
> >>> b
> datetime.datetime(2023, 9, 25, 14, 22, 36, 251705,
> tzinfo=datetime.timezone(datetime.timedelta(seconds=10800), 'EEST')) {code}
> See [PEP 495|https://peps.python.org/pep-0495/]
>
--
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-18335) Push LocalSessions info logs to debug
[ https://issues.apache.org/jira/browse/CASSANDRA-18335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17799032#comment-17799032 ] Arun Ganesh commented on CASSANDRA-18335: - [~brandon.williams], I'm a new contributor, and I'd like to work on this if it's available. Seems trivial. Is that the only line you want changed? > Push LocalSessions info logs to debug > - > > Key: CASSANDRA-18335 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18335 > Project: Cassandra > Issue Type: Improvement > Components: Consistency/Repair >Reporter: Brandon Williams >Priority: Normal > Fix For: 4.0.x, 4.1.x, 5.x > > > I don't think these are particularly useful to have at info, but the impetus > for this ticket is specifically [this > message|https://github.com/apache/cassandra/blob/cassandra-4.0/src/java/org/apache/cassandra/repair/consistent/LocalSessions.java#L456] > during automatic cleanup about skipping deleting sessions that seems to > confuse or alarm people. -- 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-19150) Make alignment of values in rows in CQLSH configurable.
[
https://issues.apache.org/jira/browse/CASSANDRA-19150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arun Ganesh reassigned CASSANDRA-19150:
---
Assignee: Arun Ganesh
> Make alignment of values in rows in CQLSH configurable.
> ---
>
> Key: CASSANDRA-19150
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19150
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Stefan Miklosovic
>Assignee: Arun Ganesh
>Priority: Low
> Fix For: 5.x
>
> Attachments: Screenshot 2023-12-04 at 00.38.16.png, Screenshot
> 2023-12-09 at 16.58.25.png, signature.asc
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We need to make this
> https://github.com/apache/cassandra/blob/trunk/pylib/cqlshlib/cqlshmain.py#L1101
> configurable so values in columns are either all on left or on right side of
> the column (basically change col.rjust to col.ljust).
> By default, it would be like it is now but there would be configuration
> property in cqlsh for that as well as a corresponding CQLSH command
> (optional), something like
> {code}
> ALIGNMENT LEFT|RIGHT
> {code}
> cc [~bschoeni]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18879) Modernize CQLSH datetime conversions
[
https://issues.apache.org/jira/browse/CASSANDRA-18879?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arun Ganesh updated CASSANDRA-18879:
Attachment: cassandra-cqlsh-stdout
> Modernize CQLSH datetime conversions
>
>
> Key: CASSANDRA-18879
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18879
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Brad Schoening
>Assignee: Arun Ganesh
>Priority: Low
> Attachments: cassandra-cqlsh-stdout
>
> Time Spent: 2h
> Remaining Estimate: 0h
>
> Python 3.x introduced many updates to datetime conversion which allows
> simplified conversions.
> 1. For example, tracing.py defines a function datetime_from_utc_to_local()
> but datetime now has a native function astimezone() which will convert UTC to
> local time.
> Review the following users of datetime which apply conversions:
> * cqlshmain.py
> * formatting.py
> * tracing.py
> Example:
> {code:java}
> >>> from dateutil import tz
> >>> import datetime
> >>> a = datetime.datetime.now().astimezone(tz.tzutc())
> >>> a
> datetime.datetime(2023, 9, 25, 11, 22, 36, 251705, tzinfo=tzutc())
> >>> b = a.astimezone()
> >>> b
> datetime.datetime(2023, 9, 25, 14, 22, 36, 251705,
> tzinfo=datetime.timezone(datetime.timedelta(seconds=10800), 'EST')) {code}
> See [[PEP 495|http://example.com]]]
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18879) Modernize CQLSH datetime conversions
[
https://issues.apache.org/jira/browse/CASSANDRA-18879?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arun Ganesh updated CASSANDRA-18879:
Test and Documentation Plan:
Tested it manually.
My timezone is US/Eastern. You can see the tracing output showing the time
({{{}2024-01-16 16:18:43.599000-05:00{}}}) in my timezone and the table
containing the time in UTC ({{{}2024-01-16 21:18:43.599000+{}}}).
(See attached log file)
was:
Tested it manually.
My timezone is US/Eastern. You can see the tracing output showing the time
({{{}2024-01-16 16:18:43.599000-05:00{}}}) in my timezone and the table
containing the time in UTC ({{{}2024-01-16 21:18:43.599000+{}}}).
{code:java}
~/code/cassandra $ ./bin/cqlsh
Connected to Test Cluster at 127.0.0.1:9042
[cqlsh 6.2.0 | Cassandra 5.1-SNAPSHOT | CQL spec 3.4.7 | Native protocol v5]
Use HELP for help.
cqlsh> tracing on;
TRACING set to ON
cqlsh> CREATE KEYSPACE IF NOT EXISTS cycling
... WITH REPLICATION = {
... 'class' : 'SimpleStrategy',
... 'replication_factor' : 1
... };
Tracing session: d3d293d0-b4b4-11ee-8d07-296dcee8db28 activity
| timestamp | source |
source_elapsed | client
-+--+---++---
Execute CQL3 query | 2024-01-16
16:18:43.599000-05:00 | 127.0.0.1 | 0 | 127.0.0.1
Parsing CREATE KEYSPACE IF NOT
EXISTS cycling\nWITH REPLICATION = {\n 'class' : 'SimpleStrategy',\n
'replication_factor' : 1\n}; [Native-Transport-Requests-1] | 2024-01-16
16:18:43.606000-05:00 | 127.0.0.1 | 7582 | 127.0.0.1
Preparing statement [Native-Transport-Requests-1] | 2024-01-16
16:18:43.607000-05:00 | 127.0.0.1 | 8513 | 127.0.0.1
Reading existing values
for CAS precondition [Native-Transport-Requests-1] | 2024-01-16
16:18:43.644000-05:00 | 127.0.0.1 | 45793 | 127.0.0.1
[jira] [Updated] (CASSANDRA-18879) Modernize CQLSH datetime conversions
[
https://issues.apache.org/jira/browse/CASSANDRA-18879?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arun Ganesh updated CASSANDRA-18879:
Test and Documentation Plan:
Tested it manually.
My timezone is US/Eastern. You can see the tracing output showing the time
({{{}2024-01-16 16:18:43.599000-05:00{}}}) in my timezone and the table
containing the time in UTC ({{{}2024-01-16 21:18:43.599000+{}}}).
(See attached [log
file|https://issues.apache.org/jira/secure/attachment/13066068/cassandra-cqlsh-stdout])
was:
Tested it manually.
My timezone is US/Eastern. You can see the tracing output showing the time
({{{}2024-01-16 16:18:43.599000-05:00{}}}) in my timezone and the table
containing the time in UTC ({{{}2024-01-16 21:18:43.599000+{}}}).
(See attached log file)
> Modernize CQLSH datetime conversions
>
>
> Key: CASSANDRA-18879
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18879
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Brad Schoening
>Assignee: Arun Ganesh
>Priority: Low
> Attachments: cassandra-cqlsh-stdout
>
> Time Spent: 2h
> Remaining Estimate: 0h
>
> Python 3.x introduced many updates to datetime conversion which allows
> simplified conversions.
> 1. For example, tracing.py defines a function datetime_from_utc_to_local()
> but datetime now has a native function astimezone() which will convert UTC to
> local time.
> Review the following users of datetime which apply conversions:
> * cqlshmain.py
> * formatting.py
> * tracing.py
> Example:
> {code:java}
> >>> from dateutil import tz
> >>> import datetime
> >>> a = datetime.datetime.now().astimezone(tz.tzutc())
> >>> a
> datetime.datetime(2023, 9, 25, 11, 22, 36, 251705, tzinfo=tzutc())
> >>> b = a.astimezone()
> >>> b
> datetime.datetime(2023, 9, 25, 14, 22, 36, 251705,
> tzinfo=datetime.timezone(datetime.timedelta(seconds=10800), 'EST')) {code}
> See [[PEP 495|http://example.com]]]
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18879) Modernize CQLSH datetime conversions
[
https://issues.apache.org/jira/browse/CASSANDRA-18879?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arun Ganesh updated CASSANDRA-18879:
Test and Documentation Plan:
Tested it manually.
My timezone is US/Eastern. You can see the tracing output showing the time
({{{}2024-01-16 16:18:43.599000-05:00{}}}) in my timezone and the table
containing the time in UTC ({{{}2024-01-16 21:18:43.599000+{}}}).
{code:java}
~/code/cassandra $ ./bin/cqlsh
Connected to Test Cluster at 127.0.0.1:9042
[cqlsh 6.2.0 | Cassandra 5.1-SNAPSHOT | CQL spec 3.4.7 | Native protocol v5]
Use HELP for help.
cqlsh> tracing on;
TRACING set to ON
cqlsh> CREATE KEYSPACE IF NOT EXISTS cycling
... WITH REPLICATION = {
... 'class' : 'SimpleStrategy',
... 'replication_factor' : 1
... };
Tracing session: d3d293d0-b4b4-11ee-8d07-296dcee8db28 activity
| timestamp | source |
source_elapsed | client
-+--+---++---
Execute CQL3 query | 2024-01-16
16:18:43.599000-05:00 | 127.0.0.1 | 0 | 127.0.0.1
Parsing CREATE KEYSPACE IF NOT
EXISTS cycling\nWITH REPLICATION = {\n 'class' : 'SimpleStrategy',\n
'replication_factor' : 1\n}; [Native-Transport-Requests-1] | 2024-01-16
16:18:43.606000-05:00 | 127.0.0.1 | 7582 | 127.0.0.1
Preparing statement [Native-Transport-Requests-1] | 2024-01-16
16:18:43.607000-05:00 | 127.0.0.1 | 8513 | 127.0.0.1
Reading existing values
for CAS precondition [Native-Transport-Requests-1] | 2024-01-16
16:18:43.644000-05:00 | 127.0.0.1 | 45793 | 127.0.0.1
[jira] [Commented] (CASSANDRA-19150) Make alignment of values in rows in CQLSH configurable.
[
https://issues.apache.org/jira/browse/CASSANDRA-19150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17798640#comment-17798640
]
Arun Ganesh commented on CASSANDRA-19150:
-
[~bschoeni], if this is up for grabs, I'd like to work on it.
> Make alignment of values in rows in CQLSH configurable.
> ---
>
> Key: CASSANDRA-19150
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19150
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Stefan Miklosovic
>Priority: Low
> Fix For: 5.x
>
> Attachments: Screenshot 2023-12-04 at 00.38.16.png, Screenshot
> 2023-12-09 at 16.58.25.png, signature.asc
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We need to make this
> https://github.com/apache/cassandra/blob/trunk/pylib/cqlshlib/cqlshmain.py#L1101
> configurable so values in columns are either all on left or on right side of
> the column (basically change col.rjust to col.ljust).
> By default, it would be like it is now but there would be configuration
> property in cqlsh for that as well as a corresponding CQLSH command
> (optional), something like
> {code}
> ALIGNMENT LEFT|RIGHT
> {code}
> cc [~bschoeni]
--
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-18879) Modernize CQLSH datetime conversions
[
https://issues.apache.org/jira/browse/CASSANDRA-18879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17792226#comment-17792226
]
Arun Ganesh commented on CASSANDRA-18879:
-
Hi [~bschoeni]
Sorry, I was caught up with my finals (because end of semester).
I did change the functions in `tracing.py`. I tried running the
`cassandra-cqlsh-tests.sh` to see if nothing is broken. But, some of the tests
timed out (both with and without the changes). How can I test my changes?
Additionally, `formatting.py` uses a function called `datetime_from_timestamp`
from the Datastax driver
([source|https://github.com/datastax/python-driver/blob/master/cassandra/util.py#L53]).
It doesn't seem to be using any of the Python 2 specific datetime functions.
How should I go about changing this?
Thanks!
> Modernize CQLSH datetime conversions
>
>
> Key: CASSANDRA-18879
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18879
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Brad Schoening
>Assignee: Arun Ganesh
>Priority: Low
>
> Python 3.x introduced many updates to datetime conversion which allows
> simplified conversions.
> 1. For example, tracing.py defines a function datetime_from_utc_to_local()
> but datetime now has a native function astimezone() which will convert UTC to
> local time.
> Review the following users of datetime which apply conversions:
> * cqlshmain.py
> * formatting.py
> * tracing.py
> Example:
> {code:java}
> >>> a = datetime.datetime.now().astimezone(tz.tzutc())
> >>> a
> datetime.datetime(2023, 9, 25, 11, 22, 36, 251705, tzinfo=tzutc())
> >>> b = a.astimezone()
> >>> b
> datetime.datetime(2023, 9, 25, 14, 22, 36, 251705,
> tzinfo=datetime.timezone(datetime.timedelta(seconds=10800), 'EEST')) {code}
> See [PEP 495|https://peps.python.org/pep-0495/]
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18879) Modernize CQLSH datetime conversions
[
https://issues.apache.org/jira/browse/CASSANDRA-18879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17792226#comment-17792226
]
Arun Ganesh edited comment on CASSANDRA-18879 at 12/1/23 10:32 PM:
---
Hi [~bschoeni]
Sorry, I was caught up with my finals (because end of semester).
I did change the functions in `tracing.py`. I tried running the
`cassandra-cqlsh-tests.sh` to see if nothing is broken. But, some of the tests
timed out (both with and without the changes). How can I test my changes?
Additionally, `formatting.py` uses a function called `datetime_from_timestamp`
from the Datastax driver
([source|https://github.com/datastax/python-driver/blob/master/cassandra/util.py#L53]).
It doesn't seem to be using any of the Python 2 specific datetime functions.
Should I change this too?
Thanks!
was (Author: JIRAUSER303038):
Hi [~bschoeni]
Sorry, I was caught up with my finals (because end of semester).
I did change the functions in `tracing.py`. I tried running the
`cassandra-cqlsh-tests.sh` to see if nothing is broken. But, some of the tests
timed out (both with and without the changes). How can I test my changes?
Additionally, `formatting.py` uses a function called `datetime_from_timestamp`
from the Datastax driver
([source|https://github.com/datastax/python-driver/blob/master/cassandra/util.py#L53]).
It doesn't seem to be using any of the Python 2 specific datetime functions.
How should I go about changing this?
Thanks!
> Modernize CQLSH datetime conversions
>
>
> Key: CASSANDRA-18879
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18879
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Brad Schoening
>Assignee: Arun Ganesh
>Priority: Low
>
> Python 3.x introduced many updates to datetime conversion which allows
> simplified conversions.
> 1. For example, tracing.py defines a function datetime_from_utc_to_local()
> but datetime now has a native function astimezone() which will convert UTC to
> local time.
> Review the following users of datetime which apply conversions:
> * cqlshmain.py
> * formatting.py
> * tracing.py
> Example:
> {code:java}
> >>> a = datetime.datetime.now().astimezone(tz.tzutc())
> >>> a
> datetime.datetime(2023, 9, 25, 11, 22, 36, 251705, tzinfo=tzutc())
> >>> b = a.astimezone()
> >>> b
> datetime.datetime(2023, 9, 25, 14, 22, 36, 251705,
> tzinfo=datetime.timezone(datetime.timedelta(seconds=10800), 'EEST')) {code}
> See [PEP 495|https://peps.python.org/pep-0495/]
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18879) Modernize CQLSH datetime conversions
[
https://issues.apache.org/jira/browse/CASSANDRA-18879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17792226#comment-17792226
]
Arun Ganesh edited comment on CASSANDRA-18879 at 12/1/23 10:32 PM:
---
Hi [~bschoeni]
Sorry, I was caught up with my finals (because end of semester).
I did change the functions in `tracing.py`. I tried running the
`cassandra-cqlsh-tests.sh` to see if nothing is broken. But, some of the tests
timed out (both with and without the changes). How can I test my changes?
Additionally, `formatting.py` uses a function called `datetime_from_timestamp`
from the Datastax driver
([source|https://github.com/datastax/python-driver/blob/master/cassandra/util.py#L53]).
It doesn't seem to be using any of the Python 2 specific datetime functions.
Should I change this too?
Thanks!
was (Author: JIRAUSER303038):
Hi [~bschoeni]
Sorry, I was caught up with my finals (because end of semester).
I did change the functions in `tracing.py`. I tried running the
`cassandra-cqlsh-tests.sh` to see if nothing is broken. But, some of the tests
timed out (both with and without the changes). How can I test my changes?
Additionally, `formatting.py` uses a function called `datetime_from_timestamp`
from the Datastax driver
([source|https://github.com/datastax/python-driver/blob/master/cassandra/util.py#L53]).
It doesn't seem to be using any of the Python 2 specific datetime functions.
Should I change this too?
Thanks!
> Modernize CQLSH datetime conversions
>
>
> Key: CASSANDRA-18879
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18879
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Brad Schoening
>Assignee: Arun Ganesh
>Priority: Low
>
> Python 3.x introduced many updates to datetime conversion which allows
> simplified conversions.
> 1. For example, tracing.py defines a function datetime_from_utc_to_local()
> but datetime now has a native function astimezone() which will convert UTC to
> local time.
> Review the following users of datetime which apply conversions:
> * cqlshmain.py
> * formatting.py
> * tracing.py
> Example:
> {code:java}
> >>> a = datetime.datetime.now().astimezone(tz.tzutc())
> >>> a
> datetime.datetime(2023, 9, 25, 11, 22, 36, 251705, tzinfo=tzutc())
> >>> b = a.astimezone()
> >>> b
> datetime.datetime(2023, 9, 25, 14, 22, 36, 251705,
> tzinfo=datetime.timezone(datetime.timedelta(seconds=10800), 'EEST')) {code}
> See [PEP 495|https://peps.python.org/pep-0495/]
>
--
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-18879) Modernize CQLSH datetime conversions
[
https://issues.apache.org/jira/browse/CASSANDRA-18879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17792241#comment-17792241
]
Arun Ganesh commented on CASSANDRA-18879:
-
> The method date_time_from_timestamp is indeed imported from the driver and
> used exactly one. Are you suggesting there is a better replacement?
No, I was just asking if I had to modify that too. Then, there's nothing to
modify in `formatting.py`. Let me raise a PR so that you can see the changes.
> Hum, it shouldn't timeout except occasionally. They run fine for me on a
> MacBook Air with Cassandra installed locally. Your machine isn't swapping is
> it (free -m)?
Let me check again. So, can I assume if the `cassandra-cqlsh-tests.sh` passes,
nothing is breaking?
> Modernize CQLSH datetime conversions
>
>
> Key: CASSANDRA-18879
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18879
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Brad Schoening
>Assignee: Arun Ganesh
>Priority: Low
>
> Python 3.x introduced many updates to datetime conversion which allows
> simplified conversions.
> 1. For example, tracing.py defines a function datetime_from_utc_to_local()
> but datetime now has a native function astimezone() which will convert UTC to
> local time.
> Review the following users of datetime which apply conversions:
> * cqlshmain.py
> * formatting.py
> * tracing.py
> Example:
> {code:java}
> >>> a = datetime.datetime.now().astimezone(tz.tzutc())
> >>> a
> datetime.datetime(2023, 9, 25, 11, 22, 36, 251705, tzinfo=tzutc())
> >>> b = a.astimezone()
> >>> b
> datetime.datetime(2023, 9, 25, 14, 22, 36, 251705,
> tzinfo=datetime.timezone(datetime.timedelta(seconds=10800), 'EEST')) {code}
> See [PEP 495|https://peps.python.org/pep-0495/]
>
--
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-19583) Make 0 work as 0+unit for all three config classes (DataStorageSpec, DurationSpec, DataRateSpec)
[
https://issues.apache.org/jira/browse/CASSANDRA-19583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arun Ganesh reassigned CASSANDRA-19583:
---
Assignee: Arun Ganesh
> Make 0 work as 0+unit for all three config classes (DataStorageSpec,
> DurationSpec, DataRateSpec)
>
>
> Key: CASSANDRA-19583
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19583
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Jon Haddad
>Assignee: Arun Ganesh
>Priority: Normal
> Fix For: 4.1.x, 5.0.x, 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The inline docs say:
> {noformat}
> Setting this to 0 disables throttling.
> {noformat}
> However, on startup, we throw this error:
> {noformat}
> Caused by: java.lang.IllegalArgumentException: Invalid data rate: 0 Accepted
> units: MiB/s, KiB/s, B/s where case matters and only non-negative values a>
> Apr 23 23:12:01 cassandra0 cassandra[3424]: at
> org.apache.cassandra.config.DataRateSpec.(DataRateSpec.java:52)
> Apr 23 23:12:01 cassandra0 cassandra[3424]: at
> org.apache.cassandra.config.DataRateSpec.(DataRateSpec.java:61)
> Apr 23 23:12:01 cassandra0 cassandra[3424]: at
> org.apache.cassandra.config.DataRateSpec$LongBytesPerSecondBound.(DataRateSpec.java:232)
> Apr 23 23:12:01 cassandra0 cassandra[3424]: ... 27 common frames
> omitted
> {noformat}
> We should allow 0 without a unit attached for data, duration, and data spec
> config parameters, as 0 is always 0 no matter the unit.
--
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-19583) Make 0 work as 0+unit for all three config classes (DataStorageSpec, DurationSpec, DataRateSpec)
[
https://issues.apache.org/jira/browse/CASSANDRA-19583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17845124#comment-17845124
]
Arun Ganesh commented on CASSANDRA-19583:
-
I've a patch ready for trunk. Let me know if it's okay. Also, should I add more
tests and change the exception's message to indicate "0" is now allowed?
> Make 0 work as 0+unit for all three config classes (DataStorageSpec,
> DurationSpec, DataRateSpec)
>
>
> Key: CASSANDRA-19583
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19583
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Jon Haddad
>Assignee: Arun Ganesh
>Priority: Normal
> Fix For: 4.1.x, 5.0.x, 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The inline docs say:
> {noformat}
> Setting this to 0 disables throttling.
> {noformat}
> However, on startup, we throw this error:
> {noformat}
> Caused by: java.lang.IllegalArgumentException: Invalid data rate: 0 Accepted
> units: MiB/s, KiB/s, B/s where case matters and only non-negative values a>
> Apr 23 23:12:01 cassandra0 cassandra[3424]: at
> org.apache.cassandra.config.DataRateSpec.(DataRateSpec.java:52)
> Apr 23 23:12:01 cassandra0 cassandra[3424]: at
> org.apache.cassandra.config.DataRateSpec.(DataRateSpec.java:61)
> Apr 23 23:12:01 cassandra0 cassandra[3424]: at
> org.apache.cassandra.config.DataRateSpec$LongBytesPerSecondBound.(DataRateSpec.java:232)
> Apr 23 23:12:01 cassandra0 cassandra[3424]: ... 27 common frames
> omitted
> {noformat}
> We should allow 0 without a unit attached for data, duration, and data spec
> config parameters, as 0 is always 0 no matter the unit.
--
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-18879) Modernize CQLSH datetime conversions
[
https://issues.apache.org/jira/browse/CASSANDRA-18879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17824128#comment-17824128
]
Arun Ganesh commented on CASSANDRA-18879:
-
Thanks, everyone! My first PR :)
> Modernize CQLSH datetime conversions
>
>
> Key: CASSANDRA-18879
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18879
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Brad Schoening
>Assignee: Arun Ganesh
>Priority: Low
> Fix For: 5.1-alpha1
>
> Attachments: cassandra-cqlsh-stdout
>
> Time Spent: 2h
> Remaining Estimate: 0h
>
> Python 3.x introduced many updates to datetime conversion which allows
> simplified conversions.
> 1. For example, tracing.py defines a function datetime_from_utc_to_local()
> but datetime now has a native function astimezone() which will convert UTC to
> local time.
> Review the following users of datetime which apply conversions:
> * cqlshmain.py
> * formatting.py
> * tracing.py
> Example:
> {code:java}
> >>> from dateutil import tz
> >>> import datetime
> >>> a = datetime.datetime.now().astimezone(tz.tzutc())
> >>> a
> datetime.datetime(2023, 9, 25, 11, 22, 36, 251705, tzinfo=tzutc())
> >>> b = a.astimezone()
> >>> b
> datetime.datetime(2023, 9, 25, 14, 22, 36, 251705,
> tzinfo=datetime.timezone(datetime.timedelta(seconds=10800), 'EST')) {code}
> See [[PEP 495|http://example.com]]]
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19454) Revert switch to approximate time in Dispatcher to avoid mixing with nanoTime() in downstream timeout calculations
[
https://issues.apache.org/jira/browse/CASSANDRA-19454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arun Ganesh updated CASSANDRA-19454:
Test and Documentation Plan: CI passed (summary attached)
Status: Patch Available (was: In Progress)
> Revert switch to approximate time in Dispatcher to avoid mixing with
> nanoTime() in downstream timeout calculations
> --
>
> Key: CASSANDRA-19454
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19454
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client
>Reporter: Caleb Rackliffe
>Assignee: Arun Ganesh
>Priority: Normal
> Fix For: 5.0.x, 5.x
>
> Attachments: ci_summary.html
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> CASSANDRA-15241 changed {{Dispatcher}} to use the {{approxTime}}
> implementation of {{MonotonicClock}} rather than {{nanoTime()}}, but clock
> drift between the two, can potentially cause queries to time out more
> quickly. We should be able to revert the {{Dispatcher}} to use {{nanoTime()}}
> again and similarly change {{QueriesTable} to {{nanoTime()}} as well for
> consistency.
--
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-19454) Revert switch to approximate time in Dispatcher to avoid mixing with nanoTime() in downstream timeout calculations
[
https://issues.apache.org/jira/browse/CASSANDRA-19454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17824134#comment-17824134
]
Arun Ganesh commented on CASSANDRA-19454:
-
Done.
I had to fix the commit message on the trunk PR and add a newline on one of the
imports. I force pushed. Hope that is fine.
> Revert switch to approximate time in Dispatcher to avoid mixing with
> nanoTime() in downstream timeout calculations
> --
>
> Key: CASSANDRA-19454
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19454
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client
>Reporter: Caleb Rackliffe
>Assignee: Arun Ganesh
>Priority: Normal
> Fix For: 5.0.x, 5.x
>
> Attachments: ci_summary.html
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> CASSANDRA-15241 changed {{Dispatcher}} to use the {{approxTime}}
> implementation of {{MonotonicClock}} rather than {{nanoTime()}}, but clock
> drift between the two, can potentially cause queries to time out more
> quickly. We should be able to revert the {{Dispatcher}} to use {{nanoTime()}}
> again and similarly change {{QueriesTable} to {{nanoTime()}} as well for
> consistency.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-19454) Revert switch to approximate time in Dispatcher to avoid mixing with nanoTime() in downstream timeout calculations
[
https://issues.apache.org/jira/browse/CASSANDRA-19454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17824134#comment-17824134
]
Arun Ganesh edited comment on CASSANDRA-19454 at 3/6/24 8:06 PM:
-
Done.
I had to fix the commit message on the trunk PR and add a newline for one of
the imports. I force pushed. Hope that is fine.
was (Author: JIRAUSER303038):
Done.
I had to fix the commit message on the trunk PR and add a newline on one of the
imports. I force pushed. Hope that is fine.
> Revert switch to approximate time in Dispatcher to avoid mixing with
> nanoTime() in downstream timeout calculations
> --
>
> Key: CASSANDRA-19454
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19454
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client
>Reporter: Caleb Rackliffe
>Assignee: Arun Ganesh
>Priority: Normal
> Fix For: 5.0.x, 5.x
>
> Attachments: ci_summary.html
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> CASSANDRA-15241 changed {{Dispatcher}} to use the {{approxTime}}
> implementation of {{MonotonicClock}} rather than {{nanoTime()}}, but clock
> drift between the two, can potentially cause queries to time out more
> quickly. We should be able to revert the {{Dispatcher}} to use {{nanoTime()}}
> again and similarly change {{QueriesTable} to {{nanoTime()}} as well for
> consistency.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18335) Push LocalSessions info logs to debug
[
https://issues.apache.org/jira/browse/CASSANDRA-18335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17825462#comment-17825462
]
Arun Ganesh edited comment on CASSANDRA-18335 at 3/11/24 9:46 PM:
--
{quote}..., I would recommend that CHANGES not be addressed in PRs, ...
{quote}
Cool.
Aside: I understand that you are super busy. Since you are already here, do you
have any tickets (a bit complex than this, for starters) that I can work on?
Almost all of the low-hanging fruit issues are taken, and the other ones seem
intimidating. I'd like to actively contribute to this project, and I got a
couple basic PRs merged recently. Thanks!
was (Author: JIRAUSER303038):
{quote}..., I would recommend that CHANGES not be addressed in PRs, ...
{quote}
Cool.
Aside: I understand that you are super busy. Since you are already here, do you
have any issues (a bit complex than this, for starters) that I can work on?
Almost all of the low-hanging fruit issues are taken, and the other ones seem
intimidating. I'd like to actively contribute to this project, and I got a
couple basic PRs merged recently. Thanks!
> Push LocalSessions info logs to debug
> -
>
> Key: CASSANDRA-18335
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18335
> Project: Cassandra
> Issue Type: Improvement
> Components: Consistency/Repair
>Reporter: Brandon Williams
>Assignee: Arun Ganesh
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.x
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> I don't think these are particularly useful to have at info, but the impetus
> for this ticket is specifically [this
> message|https://github.com/apache/cassandra/blob/cassandra-4.0/src/java/org/apache/cassandra/repair/consistent/LocalSessions.java#L456]
> during automatic cleanup about skipping deleting sessions that seems to
> confuse or alarm people.
--
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-18335) Push LocalSessions info logs to debug
[ https://issues.apache.org/jira/browse/CASSANDRA-18335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17825398#comment-17825398 ] Arun Ganesh commented on CASSANDRA-18335: - [~brandon.williams], I've changed all `logger.info` lines to `logger.debug`. Let me know if you want me to change something else. Also, I wasn't sure where to add the CHANGES.txt line for the 4.0 and 4.1 PRs. > Push LocalSessions info logs to debug > - > > Key: CASSANDRA-18335 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18335 > Project: Cassandra > Issue Type: Improvement > Components: Consistency/Repair >Reporter: Brandon Williams >Assignee: Arun Ganesh >Priority: Normal > Fix For: 4.0.x, 4.1.x, 5.x > > Time Spent: 0.5h > Remaining Estimate: 0h > > I don't think these are particularly useful to have at info, but the impetus > for this ticket is specifically [this > message|https://github.com/apache/cassandra/blob/cassandra-4.0/src/java/org/apache/cassandra/repair/consistent/LocalSessions.java#L456] > during automatic cleanup about skipping deleting sessions that seems to > confuse or alarm people. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18335) Push LocalSessions info logs to debug
[ https://issues.apache.org/jira/browse/CASSANDRA-18335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arun Ganesh updated CASSANDRA-18335: Test and Documentation Plan: Not applicable Status: Patch Available (was: In Progress) > Push LocalSessions info logs to debug > - > > Key: CASSANDRA-18335 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18335 > Project: Cassandra > Issue Type: Improvement > Components: Consistency/Repair >Reporter: Brandon Williams >Assignee: Arun Ganesh >Priority: Normal > Fix For: 4.0.x, 4.1.x, 5.x > > Time Spent: 0.5h > Remaining Estimate: 0h > > I don't think these are particularly useful to have at info, but the impetus > for this ticket is specifically [this > message|https://github.com/apache/cassandra/blob/cassandra-4.0/src/java/org/apache/cassandra/repair/consistent/LocalSessions.java#L456] > during automatic cleanup about skipping deleting sessions that seems to > confuse or alarm people. -- 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-18335) Push LocalSessions info logs to debug
[
https://issues.apache.org/jira/browse/CASSANDRA-18335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17825462#comment-17825462
]
Arun Ganesh commented on CASSANDRA-18335:
-
{quote}..., I would recommend that CHANGES not be addressed in PRs, ...
{quote}
Cool.
Aside: I understand that you are super busy. Since you are already here, do you
have any issues (a bit complex than this, for starters) that I can work on?
Almost all of the low-hanging fruit issues are taken, and the other ones seem
intimidating. I'd like to actively contribute to this project, and I got a
couple basic PRs merged recently. Thanks!
> Push LocalSessions info logs to debug
> -
>
> Key: CASSANDRA-18335
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18335
> Project: Cassandra
> Issue Type: Improvement
> Components: Consistency/Repair
>Reporter: Brandon Williams
>Assignee: Arun Ganesh
>Priority: Normal
> Fix For: 4.0.x, 4.1.x, 5.x
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> I don't think these are particularly useful to have at info, but the impetus
> for this ticket is specifically [this
> message|https://github.com/apache/cassandra/blob/cassandra-4.0/src/java/org/apache/cassandra/repair/consistent/LocalSessions.java#L456]
> during automatic cleanup about skipping deleting sessions that seems to
> confuse or alarm people.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-19150) Align values in rows in CQLSH right for numbers, left for text
[
https://issues.apache.org/jira/browse/CASSANDRA-19150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17827947#comment-17827947
]
Arun Ganesh edited comment on CASSANDRA-19150 at 3/18/24 12:13 PM:
---
Sorry, I took a while to get back to this. I have a [draft
PR|https://github.com/apache/cassandra/pull/3182] ready. I have two items to
discuss:
# I'd like some feedback on the design. The formatter for each type will
request whatever alignment it wants
like this, (I'm yet to do this on the PR)
{code:java}
return FormattedValue(val, coloredval, displaywidth,
alignment=Alignment.LEFT){code}
# I'm planning to use the following left/right alignment for the different
types (inspired from psql).
|*Type*|*Alignment*|
|default|right|
|blob/bytearray|left|
|decimal|right|
|uuid/timeuuid|left|
|inet|left|
|bool|left|
|float/double|right|
|text/unicode/ascii|left|
|set/list/map|right|
|user types|right|
When the expand mode is enabled, everything is aligned to the left, just like
in psql.
was (Author: JIRAUSER303038):
Sorry, I took a while to get back to this. I have a draft PR ready. I have two
items to discuss:
# I'd like some feedback on the design. The formatter for each type will
request whatever alignment it wants
like this, (I'm yet to do this on the PR)
{code:java}
return FormattedValue(val, coloredval, displaywidth,
alignment=Alignment.LEFT){code}
# I'm planning to use the following left/right alignment for the different
types (inspired from psql).
|*Type*|*Alignment*|
|default|right|
|blob/bytearray|left|
|decimal|right|
|uuid/timeuuid|left|
|inet|left|
|bool|left|
|float/double|right|
|text/unicode/ascii|left|
|set/list/map|right|
|user types|right|
When the expand mode is enabled, everything is aligned to the left, just like
in psql.
> Align values in rows in CQLSH right for numbers, left for text
> --
>
> Key: CASSANDRA-19150
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19150
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Stefan Miklosovic
>Assignee: Arun Ganesh
>Priority: Low
> Fix For: 5.x
>
> Attachments: Screenshot 2023-12-04 at 00.38.16.png, Screenshot
> 2023-12-09 at 16.58.25.png, signature.asc
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> *Updated* Jan 17 2024 after dev discussion
> Change CQLSH to left-align text while continue to right-align numbers. This
> will match how Postgres shell and Excel treat alignment of text and number.
> -
> *Original*
> We need to make this
> [https://github.com/apache/cassandra/blob/trunk/pylib/cqlshlib/cqlshmain.py#L1101]
> configurable so values in columns are either all on left or on right side of
> the column (basically change col.rjust to col.ljust).
> By default, it would be like it is now but there would be configuration
> property in cqlsh for that as well as a corresponding CQLSH command
> (optional), something like
> {code:java}
> ALIGNMENT LEFT|RIGHT
> {code}
> cc [~bschoeni]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-19150) Align values in rows in CQLSH right for numbers, left for text
[
https://issues.apache.org/jira/browse/CASSANDRA-19150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17827947#comment-17827947
]
Arun Ganesh edited comment on CASSANDRA-19150 at 3/18/24 12:13 PM:
---
Sorry, I took a while to get back to this. I have a [draft
PR|https://github.com/apache/cassandra/pull/3182] ready. I have two items to
discuss:
# I'd like some feedback on the design. The formatter for each type will
request whatever alignment it wants
like this, (I'm yet to do this on the PR)
{code:java}
return FormattedValue(val, coloredval, displaywidth,
alignment=Alignment.LEFT){code}
# I'm planning to use the following left/right alignment for the different
types (inspired from psql).
|*Type*|*Alignment*|
|default|right|
|blob/bytearray|left|
|decimal|right|
|uuid/timeuuid|left|
|inet|left|
|bool|left|
|float/double|right|
|text/unicode/ascii|left|
|set/list/map|right|
|user types|right|
When the expand mode is enabled, everything is aligned to the left, just like
in psql.
was (Author: JIRAUSER303038):
Sorry, I took a while to get back to this. I have a [draft
PR|https://github.com/apache/cassandra/pull/3182] ready. I have two items to
discuss:
# I'd like some feedback on the design. The formatter for each type will
request whatever alignment it wants
like this, (I'm yet to do this on the PR)
{code:java}
return FormattedValue(val, coloredval, displaywidth,
alignment=Alignment.LEFT){code}
# I'm planning to use the following left/right alignment for the different
types (inspired from psql).
|*Type*|*Alignment*|
|default|right|
|blob/bytearray|left|
|decimal|right|
|uuid/timeuuid|left|
|inet|left|
|bool|left|
|float/double|right|
|text/unicode/ascii|left|
|set/list/map|right|
|user types|right|
When the expand mode is enabled, everything is aligned to the left, just like
in psql.
> Align values in rows in CQLSH right for numbers, left for text
> --
>
> Key: CASSANDRA-19150
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19150
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Stefan Miklosovic
>Assignee: Arun Ganesh
>Priority: Low
> Fix For: 5.x
>
> Attachments: Screenshot 2023-12-04 at 00.38.16.png, Screenshot
> 2023-12-09 at 16.58.25.png, signature.asc
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> *Updated* Jan 17 2024 after dev discussion
> Change CQLSH to left-align text while continue to right-align numbers. This
> will match how Postgres shell and Excel treat alignment of text and number.
> -
> *Original*
> We need to make this
> [https://github.com/apache/cassandra/blob/trunk/pylib/cqlshlib/cqlshmain.py#L1101]
> configurable so values in columns are either all on left or on right side of
> the column (basically change col.rjust to col.ljust).
> By default, it would be like it is now but there would be configuration
> property in cqlsh for that as well as a corresponding CQLSH command
> (optional), something like
> {code:java}
> ALIGNMENT LEFT|RIGHT
> {code}
> cc [~bschoeni]
--
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-19150) Align values in rows in CQLSH right for numbers, left for text
[
https://issues.apache.org/jira/browse/CASSANDRA-19150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17827947#comment-17827947
]
Arun Ganesh commented on CASSANDRA-19150:
-
Sorry, I took a while to get back to this. I have a draft PR ready. I have two
items to discuss:
# I'd like some feedback on the design. The formatter for each type will
request whatever alignment it wants
like this, (I'm yet to do this on the PR)
{code:java}
return FormattedValue(val, coloredval, displaywidth,
alignment=Alignment.LEFT){code}
# I'm planning to use the following left/right alignment for the different
types (inspired from psql).
|*Type*|*Alignment*|
|default|right|
|blob/bytearray|left|
|decimal|right|
|uuid/timeuuid|left|
|inet|left|
|bool|left|
|float/double|right|
|text/unicode/ascii|left|
|set/list/map|right|
|user types|right|
When the expand mode is enabled, everything is aligned to the left, just like
in psql.
> Align values in rows in CQLSH right for numbers, left for text
> --
>
> Key: CASSANDRA-19150
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19150
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Stefan Miklosovic
>Assignee: Arun Ganesh
>Priority: Low
> Fix For: 5.x
>
> Attachments: Screenshot 2023-12-04 at 00.38.16.png, Screenshot
> 2023-12-09 at 16.58.25.png, signature.asc
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> *Updated* Jan 17 2024 after dev discussion
> Change CQLSH to left-align text while continue to right-align numbers. This
> will match how Postgres shell and Excel treat alignment of text and number.
> -
> *Original*
> We need to make this
> [https://github.com/apache/cassandra/blob/trunk/pylib/cqlshlib/cqlshmain.py#L1101]
> configurable so values in columns are either all on left or on right side of
> the column (basically change col.rjust to col.ljust).
> By default, it would be like it is now but there would be configuration
> property in cqlsh for that as well as a corresponding CQLSH command
> (optional), something like
> {code:java}
> ALIGNMENT LEFT|RIGHT
> {code}
> cc [~bschoeni]
--
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-19150) Align values in rows in CQLSH right for numbers, left for text
[
https://issues.apache.org/jira/browse/CASSANDRA-19150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17827951#comment-17827951
]
Arun Ganesh commented on CASSANDRA-19150:
-
Additionally,
# I noticed some deadcode. There are multiple places with code like this,
{code:java}
return bval if colormap is NO_COLOR_MAP else ...
{code}
When the {{--no-color}} flag is passed, or the tty is "dumb", we do this
{code:python}
if addcolor is False:
colormap = empty_colormap
{code}
where {{{}empty_colormap = defaultdict(lambda: ''){}}}. The {{NO_COLOR_MAP}} is
just a plain {{{}dict(){}}}.
{{colormap is NO_COLOR_MAP}} will always be {{{}False{}}}.
{code:python}
$ python3
Python 3.8.18 (default, Dec 16 2023, 04:10:16)
>>> from collections import defaultdict
>>> a = defaultdict(lambda: '')
>>> b = dict()
>>> a is b
False{code}
# I found two formatter functions for the `duration` type. Is there a
difference between `Duration` and `duration`?
{code:python}
formatter_for('duration')(format_integer_type)
.
.
.
@formatter_for('Duration')
def format_value_duration(val, colormap, **_):
return format_python_formatted_type(duration_as_str(val.months, val.days,
val.nanoseconds), colormap, 'duration'){code}
The second one is picked up always.
> Align values in rows in CQLSH right for numbers, left for text
> --
>
> Key: CASSANDRA-19150
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19150
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Stefan Miklosovic
>Assignee: Arun Ganesh
>Priority: Low
> Fix For: 5.x
>
> Attachments: Screenshot 2023-12-04 at 00.38.16.png, Screenshot
> 2023-12-09 at 16.58.25.png, signature.asc
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> *Updated* Jan 17 2024 after dev discussion
> Change CQLSH to left-align text while continue to right-align numbers. This
> will match how Postgres shell and Excel treat alignment of text and number.
> -
> *Original*
> We need to make this
> [https://github.com/apache/cassandra/blob/trunk/pylib/cqlshlib/cqlshmain.py#L1101]
> configurable so values in columns are either all on left or on right side of
> the column (basically change col.rjust to col.ljust).
> By default, it would be like it is now but there would be configuration
> property in cqlsh for that as well as a corresponding CQLSH command
> (optional), something like
> {code:java}
> ALIGNMENT LEFT|RIGHT
> {code}
> cc [~bschoeni]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-19150) Align values in rows in CQLSH right for numbers, left for text
[
https://issues.apache.org/jira/browse/CASSANDRA-19150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17827951#comment-17827951
]
Arun Ganesh edited comment on CASSANDRA-19150 at 3/18/24 12:33 PM:
---
Additionally,
# I noticed some deadcode. There are multiple places with code like this,
{code:java}
return bval if colormap is NO_COLOR_MAP else ...
{code}
When the {{--no-color}} flag is passed, or the tty is "dumb", we do this
{code:python}
if addcolor is False:
colormap = empty_colormap
{code}
where {{{}empty_colormap = defaultdict(lambda: ''){}}}. The {{NO_COLOR_MAP}} is
just a plain {{{}dict(){}}}.
{{colormap is NO_COLOR_MAP}} will always be {{{}False{}}}.
{code:python}
$ python3
Python 3.8.18 (default, Dec 16 2023, 04:10:16)
>>> from collections import defaultdict
>>> a = defaultdict(lambda: '')
>>> b = dict()
>>> a is b
False{code}
# I found two formatter functions for the `duration` type. Is there a
difference between `Duration` and `duration`?
{code:python}
formatter_for('duration')(format_integer_type)
.
.
.
@formatter_for('Duration')
def format_value_duration(val, colormap, **_):
return format_python_formatted_type(duration_as_str(val.months, val.days,
val.nanoseconds), colormap, 'duration'){code}
The second one is picked up always.
was (Author: JIRAUSER303038):
Additionally,
# I noticed some deadcode. There are multiple places with code like this,
{code:java}
return bval if colormap is NO_COLOR_MAP else ...
{code}
When the {{--no-color}} flag is passed, or the tty is "dumb", we do this
{code:python}
if addcolor is False:
colormap = empty_colormap
{code}
where {{{}empty_colormap = defaultdict(lambda: ''){}}}. The {{NO_COLOR_MAP}} is
just a plain {{{}dict(){}}}.
{{colormap is NO_COLOR_MAP}} will always be {{{}False{}}}.
{code:python}
$ python3
Python 3.8.18 (default, Dec 16 2023, 04:10:16)
>>> from collections import defaultdict
>>> a = defaultdict(lambda: '')
>>> b = dict()
>>> a is b
False{code}
# I found two formatter functions for the `duration` type. Is there a
difference between `Duration` and `duration`?
{code:python}
formatter_for('duration')(format_integer_type)
.
.
.
@formatter_for('Duration')
def format_value_duration(val, colormap, **_):
return format_python_formatted_type(duration_as_str(val.months, val.days,
val.nanoseconds), colormap, 'duration'){code}
The second one is picked up always.
> Align values in rows in CQLSH right for numbers, left for text
> --
>
> Key: CASSANDRA-19150
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19150
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Stefan Miklosovic
>Assignee: Arun Ganesh
>Priority: Low
> Fix For: 5.x
>
> Attachments: Screenshot 2023-12-04 at 00.38.16.png, Screenshot
> 2023-12-09 at 16.58.25.png, signature.asc
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> *Updated* Jan 17 2024 after dev discussion
> Change CQLSH to left-align text while continue to right-align numbers. This
> will match how Postgres shell and Excel treat alignment of text and number.
> -
> *Original*
> We need to make this
> [https://github.com/apache/cassandra/blob/trunk/pylib/cqlshlib/cqlshmain.py#L1101]
> configurable so values in columns are either all on left or on right side of
> the column (basically change col.rjust to col.ljust).
> By default, it would be like it is now but there would be configuration
> property in cqlsh for that as well as a corresponding CQLSH command
> (optional), something like
> {code:java}
> ALIGNMENT LEFT|RIGHT
> {code}
> cc [~bschoeni]
--
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-18335) Push LocalSessions info logs to debug
[ https://issues.apache.org/jira/browse/CASSANDRA-18335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17827284#comment-17827284 ] Arun Ganesh commented on CASSANDRA-18335: - Thanks! I'll close the PRs now. > Push LocalSessions info logs to debug > - > > Key: CASSANDRA-18335 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18335 > Project: Cassandra > Issue Type: Improvement > Components: Consistency/Repair >Reporter: Brandon Williams >Assignee: Arun Ganesh >Priority: Normal > Fix For: 4.0.13, 4.1.5, 5.0-beta2, 5.1 > > Time Spent: 0.5h > Remaining Estimate: 0h > > I don't think these are particularly useful to have at info, but the impetus > for this ticket is specifically [this > message|https://github.com/apache/cassandra/blob/cassandra-4.0/src/java/org/apache/cassandra/repair/consistent/LocalSessions.java#L456] > during automatic cleanup about skipping deleting sessions that seems to > confuse or alarm people. -- 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-19487) Rework json testing
[ https://issues.apache.org/jira/browse/CASSANDRA-19487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arun Ganesh reassigned CASSANDRA-19487: --- Assignee: Arun Ganesh > Rework json testing > --- > > Key: CASSANDRA-19487 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19487 > Project: Cassandra > Issue Type: Improvement > Components: Test/dtest/python >Reporter: Brandon Williams >Assignee: Arun Ganesh >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.0.x, 5.x > > > The only real json testing we have is in [this > dtest|https://github.com/apache/cassandra-dtest/blob/trunk/json_test.py] > which is full of magic like running from the tests' docstrings which makes > other things very difficult, like adding any kind of version-based variation. > I propose rewriting this, either as sane python or a java dtest. -- 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-19454) Revert switch to approximate time in Dispatcher to avoid mixing with nanoTime() in downstream timeout calculations
[
https://issues.apache.org/jira/browse/CASSANDRA-19454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17823818#comment-17823818
]
Arun Ganesh commented on CASSANDRA-19454:
-
Thanks!
Meanwhile, if you have any issues lying around that can help me understand the
project better, I'd like to work on them.
> Revert switch to approximate time in Dispatcher to avoid mixing with
> nanoTime() in downstream timeout calculations
> --
>
> Key: CASSANDRA-19454
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19454
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client
>Reporter: Caleb Rackliffe
>Assignee: Arun Ganesh
>Priority: Normal
> Fix For: 5.0.x, 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> CASSANDRA-15241 changed {{Dispatcher}} to use the {{approxTime}}
> implementation of {{MonotonicClock}} rather than {{nanoTime()}}, but clock
> drift between the two, can potentially cause queries to time out more
> quickly. We should be able to revert the {{Dispatcher}} to use {{nanoTime()}}
> again and similarly change {{QueriesTable} to {{nanoTime()}} as well for
> consistency.
--
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-18335) Push LocalSessions info logs to debug
[ https://issues.apache.org/jira/browse/CASSANDRA-18335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arun Ganesh reassigned CASSANDRA-18335: --- Assignee: Arun Ganesh > Push LocalSessions info logs to debug > - > > Key: CASSANDRA-18335 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18335 > Project: Cassandra > Issue Type: Improvement > Components: Consistency/Repair >Reporter: Brandon Williams >Assignee: Arun Ganesh >Priority: Normal > Fix For: 4.0.x, 4.1.x, 5.x > > > I don't think these are particularly useful to have at info, but the impetus > for this ticket is specifically [this > message|https://github.com/apache/cassandra/blob/cassandra-4.0/src/java/org/apache/cassandra/repair/consistent/LocalSessions.java#L456] > during automatic cleanup about skipping deleting sessions that seems to > confuse or alarm people. -- 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-19150) Align values in rows in CQLSH right for numbers, left for text
[
https://issues.apache.org/jira/browse/CASSANDRA-19150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17830032#comment-17830032
]
Arun Ganesh commented on CASSANDRA-19150:
-
Ping [~bschoeni] [~smiklosovic]
The patch is almost ready. Just a quick question. The patch will break almost
every test that depends on the cqlsh output. How should I go about fixing them?
> Align values in rows in CQLSH right for numbers, left for text
> --
>
> Key: CASSANDRA-19150
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19150
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Stefan Miklosovic
>Assignee: Arun Ganesh
>Priority: Low
> Fix For: 5.x
>
> Attachments: Screenshot 2023-12-04 at 00.38.16.png, Screenshot
> 2023-12-09 at 16.58.25.png, signature.asc
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> *Updated* Jan 17 2024 after dev discussion
> Change CQLSH to left-align text while continue to right-align numbers. This
> will match how Postgres shell and Excel treat alignment of text and number.
> -
> *Original*
> We need to make this
> [https://github.com/apache/cassandra/blob/trunk/pylib/cqlshlib/cqlshmain.py#L1101]
> configurable so values in columns are either all on left or on right side of
> the column (basically change col.rjust to col.ljust).
> By default, it would be like it is now but there would be configuration
> property in cqlsh for that as well as a corresponding CQLSH command
> (optional), something like
> {code:java}
> ALIGNMENT LEFT|RIGHT
> {code}
> cc [~bschoeni]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19150) Align values in rows in CQLSH right for numbers, left for text
[
https://issues.apache.org/jira/browse/CASSANDRA-19150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arun Ganesh updated CASSANDRA-19150:
Attachment: test_output_old.txt
> Align values in rows in CQLSH right for numbers, left for text
> --
>
> Key: CASSANDRA-19150
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19150
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Stefan Miklosovic
>Assignee: Arun Ganesh
>Priority: Low
> Fix For: 5.x
>
> Attachments: Screenshot 2023-12-04 at 00.38.16.png, Screenshot
> 2023-12-09 at 16.58.25.png, signature.asc, test_output.txt,
> test_output_old.txt
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> *Updated* Jan 17 2024 after dev discussion
> Change CQLSH to left-align text while continue to right-align numbers. This
> will match how Postgres shell and Excel treat alignment of text and number.
> -
> *Original*
> We need to make this
> [https://github.com/apache/cassandra/blob/trunk/pylib/cqlshlib/cqlshmain.py#L1101]
> configurable so values in columns are either all on left or on right side of
> the column (basically change col.rjust to col.ljust).
> By default, it would be like it is now but there would be configuration
> property in cqlsh for that as well as a corresponding CQLSH command
> (optional), something like
> {code:java}
> ALIGNMENT LEFT|RIGHT
> {code}
> cc [~bschoeni]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19150) Align values in rows in CQLSH right for numbers, left for text
[
https://issues.apache.org/jira/browse/CASSANDRA-19150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arun Ganesh updated CASSANDRA-19150:
Attachment: test_output.txt
> Align values in rows in CQLSH right for numbers, left for text
> --
>
> Key: CASSANDRA-19150
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19150
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Stefan Miklosovic
>Assignee: Arun Ganesh
>Priority: Low
> Fix For: 5.x
>
> Attachments: Screenshot 2023-12-04 at 00.38.16.png, Screenshot
> 2023-12-09 at 16.58.25.png, signature.asc, test_output.txt,
> test_output_old.txt
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> *Updated* Jan 17 2024 after dev discussion
> Change CQLSH to left-align text while continue to right-align numbers. This
> will match how Postgres shell and Excel treat alignment of text and number.
> -
> *Original*
> We need to make this
> [https://github.com/apache/cassandra/blob/trunk/pylib/cqlshlib/cqlshmain.py#L1101]
> configurable so values in columns are either all on left or on right side of
> the column (basically change col.rjust to col.ljust).
> By default, it would be like it is now but there would be configuration
> property in cqlsh for that as well as a corresponding CQLSH command
> (optional), something like
> {code:java}
> ALIGNMENT LEFT|RIGHT
> {code}
> cc [~bschoeni]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-19150) Align values in rows in CQLSH right for numbers, left for text
[
https://issues.apache.org/jira/browse/CASSANDRA-19150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17832516#comment-17832516
]
Arun Ganesh edited comment on CASSANDRA-19150 at 3/31/24 3:37 AM:
--
[~bschoeni] [~smiklosovic]
Sorry for the delay again. See [^test_output_old.txt] and [^test_output.txt]
for the before and after.
These are some things I'd like to discuss before I write/fix the tests:
1. Does the [design|https://github.com/apache/cassandra/pull/3182/files] look
okay? Or, should I use a map-lookup to get type->alignment values?
2. Should nulls be treated separately (like all null values align left), or
should they be treated according to the
type of the field (like nulls in vectors align right, nulls in maps align left,
etc.)?
3. How should I align user-types and collections: left or right? I chose right
because we were aligning
everything to the right before.
4. Breaking all tests that depend on cqlsh, including downstream apps, doesn't
seem like a great thing to do. Also, C*
devs should not be burdened with type-alignment when they write tests---there
should be a way to turn type-based
alignment on/off. I suggest that we also introduce the `ALIGNMENT` command from
the original description of this ticket.
It can have `LEFT|RIGHT|DEFAULT` options. `DEFAULT` will align the output based
on the types.
5. Should I document the alignment for the different types somewhere?
was (Author: JIRAUSER303038):
[~bschoeni] [~smiklosovic]
Sorry for the delay again. See [^test_output_old.txt] and [^test_output.txt]
for the before and after.
These are some things I'd like to discuss before I write/fix the tests:
1. Does the design look okay? Or, should I use a map-lookup to get
type->alignment values?
2. Should nulls be treated separately (like all null values align left), or
should they be treated according to the
type of the field (like nulls in vectors align right, nulls in maps align left,
etc.)?
3. How should I align user-types and collections: left or right? I chose right
because we were aligning
everything to the right before.
4. Breaking all tests that depend on cqlsh, including downstream apps, doesn't
seem like a great thing to do. Also, C*
devs should not be burdened with type-alignment when they write tests---there
should be a way to turn type-based
alignment on/off. I suggest that we also introduce the `ALIGNMENT` command from
the original description of this ticket.
It can have `LEFT|RIGHT|DEFAULT` options. `DEFAULT` will align the output based
on the types.
5. Should I document the alignment for the different types somewhere?
> Align values in rows in CQLSH right for numbers, left for text
> --
>
> Key: CASSANDRA-19150
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19150
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Stefan Miklosovic
>Assignee: Arun Ganesh
>Priority: Low
> Fix For: 5.x
>
> Attachments: Screenshot 2023-12-04 at 00.38.16.png, Screenshot
> 2023-12-09 at 16.58.25.png, signature.asc, test_output.txt,
> test_output_old.txt
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> *Updated* Jan 17 2024 after dev discussion
> Change CQLSH to left-align text while continue to right-align numbers. This
> will match how Postgres shell and Excel treat alignment of text and number.
> -
> *Original*
> We need to make this
> [https://github.com/apache/cassandra/blob/trunk/pylib/cqlshlib/cqlshmain.py#L1101]
> configurable so values in columns are either all on left or on right side of
> the column (basically change col.rjust to col.ljust).
> By default, it would be like it is now but there would be configuration
> property in cqlsh for that as well as a corresponding CQLSH command
> (optional), something like
> {code:java}
> ALIGNMENT LEFT|RIGHT
> {code}
> cc [~bschoeni]
--
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-19150) Align values in rows in CQLSH right for numbers, left for text
[
https://issues.apache.org/jira/browse/CASSANDRA-19150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17832516#comment-17832516
]
Arun Ganesh commented on CASSANDRA-19150:
-
[~bschoeni] [~smiklosovic]
Sorry for the delay again. See [^test_output_old.txt] and [^test_output.txt]
for the before and after.
These are some things I'd like to discuss before I write/fix the tests:
1. Does the design look okay? Or, should I use a map-lookup to get
type->alignment values?
2. Should nulls be treated separately (like all null values align left), or
should they be treated according to the
type of the field (like nulls in vectors align right, nulls in maps align left,
etc.)?
3. How should I align user-types and collections: left or right? I chose right
because we were aligning
everything to the right before.
4. Breaking all tests that depend on cqlsh, including downstream apps, doesn't
seem like a great thing to do. Also, C*
devs should not be burdened with type-alignment when they write tests---there
should be a way to turn type-based
alignment on/off. I suggest that we also introduce the `ALIGNMENT` command from
the original description of this ticket.
It can have `LEFT|RIGHT|DEFAULT` options. `DEFAULT` will align the output based
on the types.
5. Should I document the alignment for the different types somewhere?
> Align values in rows in CQLSH right for numbers, left for text
> --
>
> Key: CASSANDRA-19150
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19150
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Stefan Miklosovic
>Assignee: Arun Ganesh
>Priority: Low
> Fix For: 5.x
>
> Attachments: Screenshot 2023-12-04 at 00.38.16.png, Screenshot
> 2023-12-09 at 16.58.25.png, signature.asc, test_output.txt,
> test_output_old.txt
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> *Updated* Jan 17 2024 after dev discussion
> Change CQLSH to left-align text while continue to right-align numbers. This
> will match how Postgres shell and Excel treat alignment of text and number.
> -
> *Original*
> We need to make this
> [https://github.com/apache/cassandra/blob/trunk/pylib/cqlshlib/cqlshmain.py#L1101]
> configurable so values in columns are either all on left or on right side of
> the column (basically change col.rjust to col.ljust).
> By default, it would be like it is now but there would be configuration
> property in cqlsh for that as well as a corresponding CQLSH command
> (optional), something like
> {code:java}
> ALIGNMENT LEFT|RIGHT
> {code}
> cc [~bschoeni]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-19150) Align values in rows in CQLSH right for numbers, left for text
[
https://issues.apache.org/jira/browse/CASSANDRA-19150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17832655#comment-17832655
]
Arun Ganesh edited comment on CASSANDRA-19150 at 3/31/24 8:49 PM:
--
[~bschoeni],
It's a catch-22. To use {{print("\{0:x\}".format\(i\))}} to align values in the
column, we should know {{x}}, which should be the length of the longest value
in the column (either the longest value or the column header). And, you cannot
know {{x}} without converting them to strings in the first place.
I believe that's why we don't use {{"\{\}".format\(\)}} in cqlsh. Instead, we
convert all values to strings first (e.g.,
[here|https://github.com/apache/cassandra/blob/trunk/pylib/cqlshlib/formatting.py:251],
[here|https://github.com/apache/cassandra/blob/trunk/pylib/cqlshlib/formatting.py:331],
[here|https://github.com/apache/cassandra/blob/trunk/pylib/cqlshlib/formatting.py:349],
and so on), and later pad it manually to the max-width of each column.
was (Author: JIRAUSER303038):
[~bschoeni],
It's a catch-22. To use {{print("\{0:x\}".format(i))}} to align values in the
column, we should know {{x}}, which should be the length of the longest value
in the column (either the longest value or the column header). And, you cannot
know {{x}} without converting them to strings in the first place.
I believe that's why we don't use {{"\{\}".format()}} in cqlsh. Instead, we
convert all values to strings first (e.g.,
[here|https://github.com/apache/cassandra/blob/trunk/pylib/cqlshlib/formatting.py:251],
[here|https://github.com/apache/cassandra/blob/trunk/pylib/cqlshlib/formatting.py:331],
[here|https://github.com/apache/cassandra/blob/trunk/pylib/cqlshlib/formatting.py:349],
and so on), and later pad it manually to the max-width of each column.
> Align values in rows in CQLSH right for numbers, left for text
> --
>
> Key: CASSANDRA-19150
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19150
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Stefan Miklosovic
>Assignee: Arun Ganesh
>Priority: Low
> Fix For: 5.x
>
> Attachments: Screenshot 2023-12-04 at 00.38.16.png, Screenshot
> 2023-12-09 at 16.58.25.png, signature.asc, test_output.txt,
> test_output_old.txt
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> *Updated* Jan 17 2024 after dev discussion
> Change CQLSH to left-align text while continue to right-align numbers. This
> will match how Postgres shell and Excel treat alignment of text and number.
> -
> *Original*
> We need to make this
> [https://github.com/apache/cassandra/blob/trunk/pylib/cqlshlib/cqlshmain.py#L1101]
> configurable so values in columns are either all on left or on right side of
> the column (basically change col.rjust to col.ljust).
> By default, it would be like it is now but there would be configuration
> property in cqlsh for that as well as a corresponding CQLSH command
> (optional), something like
> {code:java}
> ALIGNMENT LEFT|RIGHT
> {code}
> cc [~bschoeni]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-19150) Align values in rows in CQLSH right for numbers, left for text
[
https://issues.apache.org/jira/browse/CASSANDRA-19150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17832655#comment-17832655
]
Arun Ganesh edited comment on CASSANDRA-19150 at 3/31/24 8:49 PM:
--
[~bschoeni],
It's a catch-22. To use {{print("\{0:x\}".format(i))}} to align values in the
column, we should know {{x}}, which should be the length of the longest value
in the column (either the longest value or the column header). And, you cannot
know {{x}} without converting them to strings in the first place.
I believe that's why we don't use {{"\{\}".format()}} in cqlsh. Instead, we
convert all values to strings first (e.g.,
[here|https://github.com/apache/cassandra/blob/trunk/pylib/cqlshlib/formatting.py:251],
[here|https://github.com/apache/cassandra/blob/trunk/pylib/cqlshlib/formatting.py:331],
[here|https://github.com/apache/cassandra/blob/trunk/pylib/cqlshlib/formatting.py:349],
and so on), and later pad it manually to the max-width of each column.
was (Author: JIRAUSER303038):
[~bschoeni],
It's a catch-22. To use {{print("{0:x}".format(i))}} to align values in the
column, we should know {{x}}, which should be the length of the longest value
in the column (either the longest value or the column header). And, you cannot
know {{x}} without converting them to strings in the first place.
I believe that's why we don't use {{"{}".format()}} in cqlsh. Instead, we
convert all values to strings first (e.g.,
[here|https://github.com/apache/cassandra/blob/trunk/pylib/cqlshlib/formatting.py:251],
[here|https://github.com/apache/cassandra/blob/trunk/pylib/cqlshlib/formatting.py:331],
[here|https://github.com/apache/cassandra/blob/trunk/pylib/cqlshlib/formatting.py:349],
and so on), and later pad it manually to the max-width of each column.
> Align values in rows in CQLSH right for numbers, left for text
> --
>
> Key: CASSANDRA-19150
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19150
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Stefan Miklosovic
>Assignee: Arun Ganesh
>Priority: Low
> Fix For: 5.x
>
> Attachments: Screenshot 2023-12-04 at 00.38.16.png, Screenshot
> 2023-12-09 at 16.58.25.png, signature.asc, test_output.txt,
> test_output_old.txt
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> *Updated* Jan 17 2024 after dev discussion
> Change CQLSH to left-align text while continue to right-align numbers. This
> will match how Postgres shell and Excel treat alignment of text and number.
> -
> *Original*
> We need to make this
> [https://github.com/apache/cassandra/blob/trunk/pylib/cqlshlib/cqlshmain.py#L1101]
> configurable so values in columns are either all on left or on right side of
> the column (basically change col.rjust to col.ljust).
> By default, it would be like it is now but there would be configuration
> property in cqlsh for that as well as a corresponding CQLSH command
> (optional), something like
> {code:java}
> ALIGNMENT LEFT|RIGHT
> {code}
> cc [~bschoeni]
--
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-19150) Align values in rows in CQLSH right for numbers, left for text
[
https://issues.apache.org/jira/browse/CASSANDRA-19150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17832655#comment-17832655
]
Arun Ganesh commented on CASSANDRA-19150:
-
[~bschoeni],
It's a catch-22. To use {{print("{0:x}".format(i))}} to align values in the
column, we should know {{x}}, which should be the length of the longest value
in the column (either the longest value or the column header). And, you cannot
know {{x}} without converting them to strings in the first place.
I believe that's why we don't use {{"{}".format()}} in cqlsh. Instead, we
convert all values to strings first (e.g.,
[here|https://github.com/apache/cassandra/blob/trunk/pylib/cqlshlib/formatting.py:251],
[here|https://github.com/apache/cassandra/blob/trunk/pylib/cqlshlib/formatting.py:331],
[here|https://github.com/apache/cassandra/blob/trunk/pylib/cqlshlib/formatting.py:349],
and so on), and later pad it manually to the max-width of each column.
> Align values in rows in CQLSH right for numbers, left for text
> --
>
> Key: CASSANDRA-19150
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19150
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Stefan Miklosovic
>Assignee: Arun Ganesh
>Priority: Low
> Fix For: 5.x
>
> Attachments: Screenshot 2023-12-04 at 00.38.16.png, Screenshot
> 2023-12-09 at 16.58.25.png, signature.asc, test_output.txt,
> test_output_old.txt
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> *Updated* Jan 17 2024 after dev discussion
> Change CQLSH to left-align text while continue to right-align numbers. This
> will match how Postgres shell and Excel treat alignment of text and number.
> -
> *Original*
> We need to make this
> [https://github.com/apache/cassandra/blob/trunk/pylib/cqlshlib/cqlshmain.py#L1101]
> configurable so values in columns are either all on left or on right side of
> the column (basically change col.rjust to col.ljust).
> By default, it would be like it is now but there would be configuration
> property in cqlsh for that as well as a corresponding CQLSH command
> (optional), something like
> {code:java}
> ALIGNMENT LEFT|RIGHT
> {code}
> cc [~bschoeni]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-19150) Align values in rows in CQLSH right for numbers, left for text
[
https://issues.apache.org/jira/browse/CASSANDRA-19150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17832655#comment-17832655
]
Arun Ganesh edited comment on CASSANDRA-19150 at 3/31/24 9:18 PM:
--
[~bschoeni],
It's a catch-22. To use {{print("\{0:x\}".format\(i\))}} to align values in the
column, we should know {{x}}, which should be the length of the longest value
in the column (either the longest value or the column header). And, you cannot
know {{x}} without converting all values in the column to strings in the first
place.
I believe that's why we don't use {{"\{\}".format\(\)}} in cqlsh. Instead, we
convert all values to strings first (e.g.,
[here|https://github.com/apache/cassandra/blob/trunk/pylib/cqlshlib/formatting.py:251],
[here|https://github.com/apache/cassandra/blob/trunk/pylib/cqlshlib/formatting.py:331],
[here|https://github.com/apache/cassandra/blob/trunk/pylib/cqlshlib/formatting.py:349],
and so on), and later pad it manually to the max-width of each column.
was (Author: JIRAUSER303038):
[~bschoeni],
It's a catch-22. To use {{print("\{0:x\}".format\(i\))}} to align values in the
column, we should know {{x}}, which should be the length of the longest value
in the column (either the longest value or the column header). And, you cannot
know {{x}} without converting them to strings in the first place.
I believe that's why we don't use {{"\{\}".format\(\)}} in cqlsh. Instead, we
convert all values to strings first (e.g.,
[here|https://github.com/apache/cassandra/blob/trunk/pylib/cqlshlib/formatting.py:251],
[here|https://github.com/apache/cassandra/blob/trunk/pylib/cqlshlib/formatting.py:331],
[here|https://github.com/apache/cassandra/blob/trunk/pylib/cqlshlib/formatting.py:349],
and so on), and later pad it manually to the max-width of each column.
> Align values in rows in CQLSH right for numbers, left for text
> --
>
> Key: CASSANDRA-19150
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19150
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Stefan Miklosovic
>Assignee: Arun Ganesh
>Priority: Low
> Fix For: 5.x
>
> Attachments: Screenshot 2023-12-04 at 00.38.16.png, Screenshot
> 2023-12-09 at 16.58.25.png, signature.asc, test_output.txt,
> test_output_old.txt
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> *Updated* Jan 17 2024 after dev discussion
> Change CQLSH to left-align text while continue to right-align numbers. This
> will match how Postgres shell and Excel treat alignment of text and number.
> -
> *Original*
> We need to make this
> [https://github.com/apache/cassandra/blob/trunk/pylib/cqlshlib/cqlshmain.py#L1101]
> configurable so values in columns are either all on left or on right side of
> the column (basically change col.rjust to col.ljust).
> By default, it would be like it is now but there would be configuration
> property in cqlsh for that as well as a corresponding CQLSH command
> (optional), something like
> {code:java}
> ALIGNMENT LEFT|RIGHT
> {code}
> cc [~bschoeni]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-19150) Align values in rows in CQLSH right for numbers, left for text
[
https://issues.apache.org/jira/browse/CASSANDRA-19150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17832655#comment-17832655
]
Arun Ganesh edited comment on CASSANDRA-19150 at 3/31/24 9:21 PM:
--
[~bschoeni],
It's a catch-22. To use {{print("\{0:x\}".format\(i\))}} to align values in the
column, we should know {{x}}, which should be the length of the longest value
in the column (either the longest value or the column header). And, you cannot
know {{x}} without converting all values in the column to strings in the first
place.
I believe that's why we don't use {{"\{\}".format\(\)}} in cqlsh. We can do it,
but it would make the code complex. Instead, we convert all values to strings
first (e.g.,
[here|https://github.com/apache/cassandra/blob/trunk/pylib/cqlshlib/formatting.py:251],
[here|https://github.com/apache/cassandra/blob/trunk/pylib/cqlshlib/formatting.py:331],
[here|https://github.com/apache/cassandra/blob/trunk/pylib/cqlshlib/formatting.py:349],
and so on), and later pad it manually to the max-width of each column.
was (Author: JIRAUSER303038):
[~bschoeni],
It's a catch-22. To use {{print("\{0:x\}".format\(i\))}} to align values in the
column, we should know {{x}}, which should be the length of the longest value
in the column (either the longest value or the column header). And, you cannot
know {{x}} without converting all values in the column to strings in the first
place.
I believe that's why we don't use {{"\{\}".format\(\)}} in cqlsh. Instead, we
convert all values to strings first (e.g.,
[here|https://github.com/apache/cassandra/blob/trunk/pylib/cqlshlib/formatting.py:251],
[here|https://github.com/apache/cassandra/blob/trunk/pylib/cqlshlib/formatting.py:331],
[here|https://github.com/apache/cassandra/blob/trunk/pylib/cqlshlib/formatting.py:349],
and so on), and later pad it manually to the max-width of each column.
> Align values in rows in CQLSH right for numbers, left for text
> --
>
> Key: CASSANDRA-19150
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19150
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Stefan Miklosovic
>Assignee: Arun Ganesh
>Priority: Low
> Fix For: 5.x
>
> Attachments: Screenshot 2023-12-04 at 00.38.16.png, Screenshot
> 2023-12-09 at 16.58.25.png, signature.asc, test_output.txt,
> test_output_old.txt
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> *Updated* Jan 17 2024 after dev discussion
> Change CQLSH to left-align text while continue to right-align numbers. This
> will match how Postgres shell and Excel treat alignment of text and number.
> -
> *Original*
> We need to make this
> [https://github.com/apache/cassandra/blob/trunk/pylib/cqlshlib/cqlshmain.py#L1101]
> configurable so values in columns are either all on left or on right side of
> the column (basically change col.rjust to col.ljust).
> By default, it would be like it is now but there would be configuration
> property in cqlsh for that as well as a corresponding CQLSH command
> (optional), something like
> {code:java}
> ALIGNMENT LEFT|RIGHT
> {code}
> cc [~bschoeni]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-19150) Align values in rows in CQLSH right for numbers, left for text
[
https://issues.apache.org/jira/browse/CASSANDRA-19150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17832655#comment-17832655
]
Arun Ganesh edited comment on CASSANDRA-19150 at 4/3/24 12:19 PM:
--
[~bschoeni],
By the time we get to calling the {{ljust\(\)}} or {{rjust\(\)}} at
https://github.com/apache/cassandra/blob/trunk/pylib/cqlshlib/cqlshmain.py#L1025,
all the values are converted to strings (e.g.,
[here|https://github.com/apache/cassandra/blob/trunk/pylib/cqlshlib/formatting.py#L251],
[here|https://github.com/apache/cassandra/blob/trunk/pylib/cqlshlib/formatting.py#L331],
[here|https://github.com/apache/cassandra/blob/trunk/pylib/cqlshlib/formatting.py#L349],
and so on).
was (Author: JIRAUSER303038):
[~bschoeni],
By the time we get to calling the {{ljust\(\)}} or {{rjust\(\)}} at
https://github.com/apache/cassandra/blob/trunk/pylib/cqlshlib/cqlshmain.py#L1025,
all the values are converted to strings (e.g.,
[here|https://github.com/apache/cassandra/blob/trunk/pylib/cqlshlib/formatting.py:251],
[here|https://github.com/apache/cassandra/blob/trunk/pylib/cqlshlib/formatting.py:331],
[here|https://github.com/apache/cassandra/blob/trunk/pylib/cqlshlib/formatting.py:349],
and so on).
> Align values in rows in CQLSH right for numbers, left for text
> --
>
> Key: CASSANDRA-19150
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19150
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Stefan Miklosovic
>Assignee: Arun Ganesh
>Priority: Low
> Fix For: 5.x
>
> Attachments: Screenshot 2023-12-04 at 00.38.16.png, Screenshot
> 2023-12-09 at 16.58.25.png, signature.asc, test_output.txt,
> test_output_old.txt
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> *Updated* Jan 17 2024 after dev discussion
> Change CQLSH to left-align text while continue to right-align numbers. This
> will match how Postgres shell and Excel treat alignment of text and number.
> -
> *Original*
> We need to make this
> [https://github.com/apache/cassandra/blob/trunk/pylib/cqlshlib/cqlshmain.py#L1101]
> configurable so values in columns are either all on left or on right side of
> the column (basically change col.rjust to col.ljust).
> By default, it would be like it is now but there would be configuration
> property in cqlsh for that as well as a corresponding CQLSH command
> (optional), something like
> {code:java}
> ALIGNMENT LEFT|RIGHT
> {code}
> cc [~bschoeni]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-19150) Align values in rows in CQLSH right for numbers, left for text
[
https://issues.apache.org/jira/browse/CASSANDRA-19150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17832655#comment-17832655
]
Arun Ganesh edited comment on CASSANDRA-19150 at 4/2/24 1:08 AM:
-
[~bschoeni],
By the time we get to calling the {{ljust\(\)}} or {{rjust\(\)}} at
https://github.com/apache/cassandra/blob/trunk/pylib/cqlshlib/cqlshmain.py#L1025,
all the values are converted to strings (e.g.,
[here|https://github.com/apache/cassandra/blob/trunk/pylib/cqlshlib/formatting.py:251],
[here|https://github.com/apache/cassandra/blob/trunk/pylib/cqlshlib/formatting.py:331],
[here|https://github.com/apache/cassandra/blob/trunk/pylib/cqlshlib/formatting.py:349],
and so on).
was (Author: JIRAUSER303038):
[~bschoeni],
It's a catch-22. To use {{print("\{0:x\}".format\(i\))}} to align values in the
column, we should know {{x}}, which should be the length of the longest value
in the column (either the longest value or the column header). And, you cannot
know {{x}} without converting all values in the column to strings in the first
place.
I believe that's why we don't use {{"\{\}".format\(\)}} in cqlsh. We can do it,
but it would make the code complex. Instead, we convert all values to strings
first (e.g.,
[here|https://github.com/apache/cassandra/blob/trunk/pylib/cqlshlib/formatting.py:251],
[here|https://github.com/apache/cassandra/blob/trunk/pylib/cqlshlib/formatting.py:331],
[here|https://github.com/apache/cassandra/blob/trunk/pylib/cqlshlib/formatting.py:349],
and so on), and later pad it manually to the max-width of each column.
> Align values in rows in CQLSH right for numbers, left for text
> --
>
> Key: CASSANDRA-19150
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19150
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Stefan Miklosovic
>Assignee: Arun Ganesh
>Priority: Low
> Fix For: 5.x
>
> Attachments: Screenshot 2023-12-04 at 00.38.16.png, Screenshot
> 2023-12-09 at 16.58.25.png, signature.asc, test_output.txt,
> test_output_old.txt
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> *Updated* Jan 17 2024 after dev discussion
> Change CQLSH to left-align text while continue to right-align numbers. This
> will match how Postgres shell and Excel treat alignment of text and number.
> -
> *Original*
> We need to make this
> [https://github.com/apache/cassandra/blob/trunk/pylib/cqlshlib/cqlshmain.py#L1101]
> configurable so values in columns are either all on left or on right side of
> the column (basically change col.rjust to col.ljust).
> By default, it would be like it is now but there would be configuration
> property in cqlsh for that as well as a corresponding CQLSH command
> (optional), something like
> {code:java}
> ALIGNMENT LEFT|RIGHT
> {code}
> cc [~bschoeni]
--
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-19362) An "include" is broken on the Storage Engine documentation page
[ https://issues.apache.org/jira/browse/CASSANDRA-19362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17821446#comment-17821446 ] Arun Ganesh commented on CASSANDRA-19362: - Hi [~polandll], I'm a new contributor, and I was looking for something to contribute. Hope you don't mind :) I've attached screenshots of the fix as well. [4.1 PR|https://github.com/apache/cassandra/pull/3148] [4.0 PR|https://github.com/apache/cassandra/pull/3149] [3.11 PR|https://github.com/apache/cassandra/pull/3150] > An "include" is broken on the Storage Engine documentation page > --- > > Key: CASSANDRA-19362 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19362 > Project: Cassandra > Issue Type: Bug > Components: Documentation >Reporter: Jeremy Hanna >Assignee: Lorina Poland >Priority: Normal > Attachments: 3.11.png, 4.0.png, 4.1.png > > Time Spent: 0.5h > Remaining Estimate: 0h > > The example code at the bottom of the "Storage Engine" page doesn't appear to > be including the code properly. See > https://cassandra.apache.org/doc/stable/cassandra/architecture/storage_engine.html#example-code -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19362) An "include" is broken on the Storage Engine documentation page
[ https://issues.apache.org/jira/browse/CASSANDRA-19362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arun Ganesh updated CASSANDRA-19362: Attachment: 3.11.png 4.0.png 4.1.png > An "include" is broken on the Storage Engine documentation page > --- > > Key: CASSANDRA-19362 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19362 > Project: Cassandra > Issue Type: Bug > Components: Documentation >Reporter: Jeremy Hanna >Assignee: Lorina Poland >Priority: Normal > Attachments: 3.11.png, 4.0.png, 4.1.png > > Time Spent: 0.5h > Remaining Estimate: 0h > > The example code at the bottom of the "Storage Engine" page doesn't appear to > be including the code properly. See > https://cassandra.apache.org/doc/stable/cassandra/architecture/storage_engine.html#example-code -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-19362) An "include" is broken on the Storage Engine documentation page
[ https://issues.apache.org/jira/browse/CASSANDRA-19362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17821446#comment-17821446 ] Arun Ganesh edited comment on CASSANDRA-19362 at 2/27/24 10:54 PM: --- Hi [~polandll], I'm a new contributor, and I was looking for something to contribute. Hope you don't mind :) I've attached screenshots of the fix as well. [4.1 PR|https://github.com/apache/cassandra/pull/3148] [4.0 PR|https://github.com/apache/cassandra/pull/3149] [3.11 PR|https://github.com/apache/cassandra/pull/3150] was (Author: JIRAUSER303038): Hi [~polandll], I'm a new contributor, and I was looking for something to contribute. Hope you don't mind :) I've attached screenshots of the fix as well. [4.1 PR|https://github.com/apache/cassandra/pull/3148] [4.0 PR|https://github.com/apache/cassandra/pull/3149] [3.11 PR|https://github.com/apache/cassandra/pull/3150] > An "include" is broken on the Storage Engine documentation page > --- > > Key: CASSANDRA-19362 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19362 > Project: Cassandra > Issue Type: Bug > Components: Documentation >Reporter: Jeremy Hanna >Assignee: Lorina Poland >Priority: Normal > Attachments: 3.11.png, 4.0.png, 4.1.png > > Time Spent: 0.5h > Remaining Estimate: 0h > > The example code at the bottom of the "Storage Engine" page doesn't appear to > be including the code properly. See > https://cassandra.apache.org/doc/stable/cassandra/architecture/storage_engine.html#example-code -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19362) An "include" is broken on the Storage Engine documentation page
[ https://issues.apache.org/jira/browse/CASSANDRA-19362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arun Ganesh updated CASSANDRA-19362: Authors: Arun Ganesh (was: Lorina Poland) Impacts: Docs (was: None) Test and Documentation Plan: See attached screenshots Status: Patch Available (was: Open) > An "include" is broken on the Storage Engine documentation page > --- > > Key: CASSANDRA-19362 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19362 > Project: Cassandra > Issue Type: Bug > Components: Documentation >Reporter: Jeremy Hanna >Assignee: Lorina Poland >Priority: Normal > Attachments: 3.11.png, 4.0.png, 4.1.png > > Time Spent: 0.5h > Remaining Estimate: 0h > > The example code at the bottom of the "Storage Engine" page doesn't appear to > be including the code properly. See > https://cassandra.apache.org/doc/stable/cassandra/architecture/storage_engine.html#example-code -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19454) Revert switch to approximate time in Dispatcher to avoid mixing with nanoTime() in downstream timeout calculations
[
https://issues.apache.org/jira/browse/CASSANDRA-19454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17822779#comment-17822779
]
Arun Ganesh commented on CASSANDRA-19454:
-
Hey [~maedhroz],
I understand you've worked on this before. But, if it's fine with you, I'd like
to work on this. I'm a new contributor, and most of the other low hanging fruit
issues are either taken or seem intimidating.
Thanks!
> Revert switch to approximate time in Dispatcher to avoid mixing with
> nanoTime() in downstream timeout calculations
> --
>
> Key: CASSANDRA-19454
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19454
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 5.0.x, 5.x
>
>
> CASSANDRA-15241 changed {{Dispatcher}} to use the {{approxTime}}
> implementation of {{MonotonicClock}} rather than {{nanoTime()}}, but clock
> drift between the two, can potentially cause queries to time out more
> quickly. We should be able to revert the {{Dispatcher}} to use {{nanoTime()}}
> again and similarly change {{QueriesTable} to {{nanoTime()}} as well for
> consistency.
--
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-19454) Revert switch to approximate time in Dispatcher to avoid mixing with nanoTime() in downstream timeout calculations
[
https://issues.apache.org/jira/browse/CASSANDRA-19454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17823466#comment-17823466
]
Arun Ganesh commented on CASSANDRA-19454:
-
[~maedhroz], thanks!
I have a [draft PR|https://github.com/apache/cassandra/pull/3158] up for trunk.
I'm not sure if that's all there is to do. Also, how should I go about testing
these changes? I'll create another PR for 5.0 after I finish this one.
> Revert switch to approximate time in Dispatcher to avoid mixing with
> nanoTime() in downstream timeout calculations
> --
>
> Key: CASSANDRA-19454
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19454
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client
>Reporter: Caleb Rackliffe
>Assignee: Arun Ganesh
>Priority: Normal
> Fix For: 5.0.x, 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> CASSANDRA-15241 changed {{Dispatcher}} to use the {{approxTime}}
> implementation of {{MonotonicClock}} rather than {{nanoTime()}}, but clock
> drift between the two, can potentially cause queries to time out more
> quickly. We should be able to revert the {{Dispatcher}} to use {{nanoTime()}}
> again and similarly change {{QueriesTable} to {{nanoTime()}} as well for
> consistency.
--
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-19400) IndexStatusManager needs to prioritize SUCCESS over UNKNOWN states to maximize availability
[
https://issues.apache.org/jira/browse/CASSANDRA-19400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17852627#comment-17852627
]
Arun Ganesh commented on CASSANDRA-19400:
-
[~maedhroz], here's a draft PR: https://github.com/apache/cassandra/pull/3350.
Let me know if it looks good.
Two questions:
1. What value should I choose for the initial capacity of the list? I can see
that we double the size of the list (and copy its contents) every time we run
out of capacity.
{code:java}
... = liveEndpoints.newBuilder(0)
{code}
2. How do I test my changes?
> IndexStatusManager needs to prioritize SUCCESS over UNKNOWN states to
> maximize availability
> ---
>
> Key: CASSANDRA-19400
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19400
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/SAI
>Reporter: Caleb Rackliffe
>Assignee: Arun Ganesh
>Priority: Low
> Fix For: 5.0.x, 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {{IndexStatusManager}} is responsible for knowing what SAI indexes are
> queryable across the ring, endpoint by endpoint. There are two statuses that
> SAI treats as queryable, but it should not treat them equally.
> {{BUILD_SUCCEEDED}} means the index is definitely available and should be
> able to serve queries without issue. {{UNKNOWN}} indicates that the status of
> the index hasn’t propagated yet to this coordinator. It may be just fine, or
> it may not be. If it isn’t a query will not return incorrect results, but it
> will fail. If there are enough {{BUILD_SUCCEEDED}} replicas, we should ignore
> {{UNKNOWN}} replicas and maximize availability. If the UNKNOWN replica is
> going to become {{BUILD_SUCCEEDED}} shortly, it will happily start taking
> requests at that point and spread the load. If not, we’ll avoid futile
> attempts to query it too early.
--
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-19671) Nodetool tabestats: add keyspace space used and table r/w ratio
[
https://issues.apache.org/jira/browse/CASSANDRA-19671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17851850#comment-17851850
]
Arun Ganesh commented on CASSANDRA-19671:
-
[~bschoeni], my bad. Attached.
I also tested the JSON and YAML output formats with,
{code:sh}
nodetool tablestats -HF yaml system
nodetool tablestats -HF json system
nodetool tablestats -F yaml system
nodetool tablestats -F json system
{code}
> Nodetool tabestats: add keyspace space used and table r/w ratio
> ---
>
> Key: CASSANDRA-19671
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19671
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Brad Schoening
>Assignee: Arun Ganesh
>Priority: Low
> Attachments: plaintext-humanreadable.txt, plaintext.txt
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Nodetool tabestats reports the space used live and total per table, but not
> for the entire keyspace. This would be useful information.
> Also, in the table level stats, it would be useful to have the read/write
> ratio. This metric is important in choosing compaction strategies such as
> LCS.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19671) Nodetool tabestats: add keyspace space used and table r/w ratio
[ https://issues.apache.org/jira/browse/CASSANDRA-19671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arun Ganesh updated CASSANDRA-19671: Attachment: plaintext.txt plaintext-humanreadable.txt > Nodetool tabestats: add keyspace space used and table r/w ratio > --- > > Key: CASSANDRA-19671 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19671 > Project: Cassandra > Issue Type: Improvement > Components: Tool/nodetool >Reporter: Brad Schoening >Assignee: Arun Ganesh >Priority: Low > Attachments: plaintext-humanreadable.txt, plaintext.txt > > Time Spent: 10m > Remaining Estimate: 0h > > Nodetool tabestats reports the space used live and total per table, but not > for the entire keyspace. This would be useful information. > Also, in the table level stats, it would be useful to have the read/write > ratio. This metric is important in choosing compaction strategies such as > LCS. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-19400) IndexStatusManager needs to prioritize SUCCESS over UNKNOWN states to maximize availability
[
https://issues.apache.org/jira/browse/CASSANDRA-19400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17851884#comment-17851884
]
Arun Ganesh edited comment on CASSANDRA-19400 at 6/4/24 4:11 AM:
-
Hey [~maedhroz], newbie here.
If I understand correctly, the {{queryableEndpoints}} returned from the
[IndexStatusManager::filterForQuery|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/index/IndexStatusManager.java#L85]
should list endpoints with {{BUILD_SUCCEEDED}} indices first? And, should this
behavior only apply to SAI indices?
was (Author: JIRAUSER303038):
Hey [~maedhroz], newbie here.
If I understand correctly, the {{queryableEndpoints}} returned from the
[IndexStatusManager::filterForQuery|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/index/IndexStatusManager.java#L85]
should list {{BUILD_SUCCEEDED}} indices first? And, should this behavior only
apply to SAI indices?
> IndexStatusManager needs to prioritize SUCCESS over UNKNOWN states to
> maximize availability
> ---
>
> Key: CASSANDRA-19400
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19400
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/SAI
>Reporter: Caleb Rackliffe
>Priority: Low
> Fix For: 5.0.x, 5.x
>
>
> {{IndexStatusManager}} is responsible for knowing what SAI indexes are
> queryable across the ring, endpoint by endpoint. There are two statuses that
> SAI treats as queryable, but it should not treat them equally.
> {{BUILD_SUCCEEDED}} means the index is definitely available and should be
> able to serve queries without issue. {{UNKNOWN}} indicates that the status of
> the index hasn’t propagated yet to this coordinator. It may be just fine, or
> it may not be. If it isn’t a query will not return incorrect results, but it
> will fail. If there are enough {{BUILD_SUCCEEDED}} replicas, we should ignore
> {{UNKNOWN}} replicas and maximize availability. If the UNKNOWN replica is
> going to become {{BUILD_SUCCEEDED}} shortly, it will happily start taking
> requests at that point and spread the load. If not, we’ll avoid futile
> attempts to query it too early.
--
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-19400) IndexStatusManager needs to prioritize SUCCESS over UNKNOWN states to maximize availability
[
https://issues.apache.org/jira/browse/CASSANDRA-19400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17851884#comment-17851884
]
Arun Ganesh commented on CASSANDRA-19400:
-
Hey [~maedhroz], newbie here.
If I understand correctly, the {{queryableEndpoints}} returned from the
[IndexStatusManager::filterForQuery|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/index/IndexStatusManager.java#L85]
should list {{BUILD_SUCCEEDED}} indices first? And, should this behavior only
apply to SAI indices?
> IndexStatusManager needs to prioritize SUCCESS over UNKNOWN states to
> maximize availability
> ---
>
> Key: CASSANDRA-19400
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19400
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/SAI
>Reporter: Caleb Rackliffe
>Priority: Low
> Fix For: 5.0.x, 5.x
>
>
> {{IndexStatusManager}} is responsible for knowing what SAI indexes are
> queryable across the ring, endpoint by endpoint. There are two statuses that
> SAI treats as queryable, but it should not treat them equally.
> {{BUILD_SUCCEEDED}} means the index is definitely available and should be
> able to serve queries without issue. {{UNKNOWN}} indicates that the status of
> the index hasn’t propagated yet to this coordinator. It may be just fine, or
> it may not be. If it isn’t a query will not return incorrect results, but it
> will fail. If there are enough {{BUILD_SUCCEEDED}} replicas, we should ignore
> {{UNKNOWN}} replicas and maximize availability. If the UNKNOWN replica is
> going to become {{BUILD_SUCCEEDED}} shortly, it will happily start taking
> requests at that point and spread the load. If not, we’ll avoid futile
> attempts to query it too early.
--
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-19671) Nodetool tabestats: add keyspace space used and table r/w ratio
[
https://issues.apache.org/jira/browse/CASSANDRA-19671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17851829#comment-17851829
]
Arun Ganesh commented on CASSANDRA-19671:
-
Yes, the ratio is calculated like this,
{code:java}
statsTable.localReadWriteRatio = statsTable.localWriteCount > 0 ?
statsTable.localReadCount / (double) statsTable.localWriteCount : 0;
{code}
> Nodetool tabestats: add keyspace space used and table r/w ratio
> ---
>
> Key: CASSANDRA-19671
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19671
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Brad Schoening
>Assignee: Arun Ganesh
>Priority: Low
>
> Nodetool tabestats reports the space used live and total per table, but not
> for the entire keyspace. This would be useful information.
> Also, in the table level stats, it would be useful to have the read/write
> ratio. This metric is important in choosing compaction strategies such as
> LCS.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-19671) Nodetool tabestats: add keyspace space used and table r/w ratio
[ https://issues.apache.org/jira/browse/CASSANDRA-19671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17851836#comment-17851836 ] Arun Ganesh edited comment on CASSANDRA-19671 at 6/3/24 10:38 PM: -- [~bschoeni], I believe the patch is ready. Let me know if it looks okay. We currently do not have any tests to validate the correctness of keyspace-level stats, like pendingFlushes, totalReadTime, etc. Let me know if I should add them. was (Author: JIRAUSER303038): I believe the patch is ready. Let me know if it looks okay. We currently do not have any tests to validate the correctness of keyspace-level stats, like pendingFlushes, totalReadTime, etc. Let me know if I should add them. > Nodetool tabestats: add keyspace space used and table r/w ratio > --- > > Key: CASSANDRA-19671 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19671 > Project: Cassandra > Issue Type: Improvement > Components: Tool/nodetool >Reporter: Brad Schoening >Assignee: Arun Ganesh >Priority: Low > Time Spent: 10m > Remaining Estimate: 0h > > Nodetool tabestats reports the space used live and total per table, but not > for the entire keyspace. This would be useful information. > Also, in the table level stats, it would be useful to have the read/write > ratio. This metric is important in choosing compaction strategies such as > LCS. -- 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-19671) Nodetool tabestats: add keyspace space used and table r/w ratio
[ https://issues.apache.org/jira/browse/CASSANDRA-19671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17851836#comment-17851836 ] Arun Ganesh commented on CASSANDRA-19671: - I believe the patch is ready. Let me know if it looks okay. We currently do not have any tests to validate the correctness of keyspace-level stats, like pendingFlushes, totalReadTime, etc. Let me know if I should add them. > Nodetool tabestats: add keyspace space used and table r/w ratio > --- > > Key: CASSANDRA-19671 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19671 > Project: Cassandra > Issue Type: Improvement > Components: Tool/nodetool >Reporter: Brad Schoening >Assignee: Arun Ganesh >Priority: Low > Time Spent: 10m > Remaining Estimate: 0h > > Nodetool tabestats reports the space used live and total per table, but not > for the entire keyspace. This would be useful information. > Also, in the table level stats, it would be useful to have the read/write > ratio. This metric is important in choosing compaction strategies such as > LCS. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-19671) Nodetool tabestats: add keyspace space used and table r/w ratio
[
https://issues.apache.org/jira/browse/CASSANDRA-19671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17851829#comment-17851829
]
Arun Ganesh edited comment on CASSANDRA-19671 at 6/3/24 10:29 PM:
--
Yes, the ratio is calculated like this,
{code:java}
statsTable.localReadWriteRatio = statsTable.localWriteCount > 0 ?
statsTable.localReadCount / (double) statsTable.localWriteCount : 0;
{code}
Since it is already present, maybe you can update the ticket.
was (Author: JIRAUSER303038):
Yes, the ratio is calculated like this,
{code:java}
statsTable.localReadWriteRatio = statsTable.localWriteCount > 0 ?
statsTable.localReadCount / (double) statsTable.localWriteCount : 0;
{code}
> Nodetool tabestats: add keyspace space used and table r/w ratio
> ---
>
> Key: CASSANDRA-19671
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19671
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Brad Schoening
>Assignee: Arun Ganesh
>Priority: Low
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Nodetool tabestats reports the space used live and total per table, but not
> for the entire keyspace. This would be useful information.
> Also, in the table level stats, it would be useful to have the read/write
> ratio. This metric is important in choosing compaction strategies such as
> LCS.
--
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-19671) Nodetool tabestats: add keyspace space used and table r/w ratio
[ https://issues.apache.org/jira/browse/CASSANDRA-19671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arun Ganesh reassigned CASSANDRA-19671: --- Assignee: Arun Ganesh > Nodetool tabestats: add keyspace space used and table r/w ratio > --- > > Key: CASSANDRA-19671 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19671 > Project: Cassandra > Issue Type: Improvement > Components: Tool/nodetool >Reporter: Brad Schoening >Assignee: Arun Ganesh >Priority: Low > > Nodetool tabestats reports the space used live and total per table, but not > for the entire keyspace. This would be useful information. > Also, in the table level stats, it would be useful to have the read/write > ratio. This metric is important in choosing compaction strategies such as > LCS. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19671) Nodetool tabestats: add keyspace space used and table r/w ratio
[ https://issues.apache.org/jira/browse/CASSANDRA-19671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arun Ganesh updated CASSANDRA-19671: Test and Documentation Plan: N/A Status: Patch Available (was: In Progress) > Nodetool tabestats: add keyspace space used and table r/w ratio > --- > > Key: CASSANDRA-19671 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19671 > Project: Cassandra > Issue Type: Improvement > Components: Tool/nodetool >Reporter: Brad Schoening >Assignee: Arun Ganesh >Priority: Low > Time Spent: 10m > Remaining Estimate: 0h > > Nodetool tabestats reports the space used live and total per table, but not > for the entire keyspace. This would be useful information. > Also, in the table level stats, it would be useful to have the read/write > ratio. This metric is important in choosing compaction strategies such as > LCS. -- 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-19400) IndexStatusManager needs to prioritize SUCCESS over UNKNOWN states to maximize availability
[
https://issues.apache.org/jira/browse/CASSANDRA-19400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17852173#comment-17852173
]
Arun Ganesh commented on CASSANDRA-19400:
-
[~maedhroz],
Thanks, I can take this up.
Just wondering if this is the right way to determine how many
{{BUILD_SUCCEEDED}} replicas are enough,
{code:java}
int required = level.blockFor(keyspace.getReplicationStrategy())
{code}
> IndexStatusManager needs to prioritize SUCCESS over UNKNOWN states to
> maximize availability
> ---
>
> Key: CASSANDRA-19400
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19400
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/SAI
>Reporter: Caleb Rackliffe
>Priority: Low
> Fix For: 5.0.x, 5.x
>
>
> {{IndexStatusManager}} is responsible for knowing what SAI indexes are
> queryable across the ring, endpoint by endpoint. There are two statuses that
> SAI treats as queryable, but it should not treat them equally.
> {{BUILD_SUCCEEDED}} means the index is definitely available and should be
> able to serve queries without issue. {{UNKNOWN}} indicates that the status of
> the index hasn’t propagated yet to this coordinator. It may be just fine, or
> it may not be. If it isn’t a query will not return incorrect results, but it
> will fail. If there are enough {{BUILD_SUCCEEDED}} replicas, we should ignore
> {{UNKNOWN}} replicas and maximize availability. If the UNKNOWN replica is
> going to become {{BUILD_SUCCEEDED}} shortly, it will happily start taking
> requests at that point and spread the load. If not, we’ll avoid futile
> attempts to query it too early.
--
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-19400) IndexStatusManager needs to prioritize SUCCESS over UNKNOWN states to maximize availability
[
https://issues.apache.org/jira/browse/CASSANDRA-19400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arun Ganesh reassigned CASSANDRA-19400:
---
Assignee: Arun Ganesh
> IndexStatusManager needs to prioritize SUCCESS over UNKNOWN states to
> maximize availability
> ---
>
> Key: CASSANDRA-19400
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19400
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/SAI
>Reporter: Caleb Rackliffe
>Assignee: Arun Ganesh
>Priority: Low
> Fix For: 5.0.x, 5.x
>
>
> {{IndexStatusManager}} is responsible for knowing what SAI indexes are
> queryable across the ring, endpoint by endpoint. There are two statuses that
> SAI treats as queryable, but it should not treat them equally.
> {{BUILD_SUCCEEDED}} means the index is definitely available and should be
> able to serve queries without issue. {{UNKNOWN}} indicates that the status of
> the index hasn’t propagated yet to this coordinator. It may be just fine, or
> it may not be. If it isn’t a query will not return incorrect results, but it
> will fail. If there are enough {{BUILD_SUCCEEDED}} replicas, we should ignore
> {{UNKNOWN}} replicas and maximize availability. If the UNKNOWN replica is
> going to become {{BUILD_SUCCEEDED}} shortly, it will happily start taking
> requests at that point and spread the load. If not, we’ll avoid futile
> attempts to query it too early.
--
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-19150) Align values in rows in CQLSH right for numbers, left for text
[
https://issues.apache.org/jira/browse/CASSANDRA-19150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17851515#comment-17851515
]
Arun Ganesh commented on CASSANDRA-19150:
-
[~bschoeni],
Thanks for the review! I'm sorry I was not available for a while because of my
finals.
#2 and #3 sounds good. For #4, I don't have the exact count because I don't
have a paid CircleCI account, and I can see some dtests using the cqlsh output
(like this
[one|https://github.com/apache/cassandra-dtest/blob/trunk/json_test.py]).
Regarding #1, everything except "This could be generalized to a multi-value map
for types" sounds good, because I see a lot of inline uses of the color map,
like
{code:python}
coloredval = colormap['text'] + bits_to_turn_red_re.sub(tbr, bval) +
colormap['reset']
{code}
Changing this map to include the alignment too would require changes in a lot
of places.
Let me update my PR.
> Align values in rows in CQLSH right for numbers, left for text
> --
>
> Key: CASSANDRA-19150
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19150
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Stefan Miklosovic
>Assignee: Arun Ganesh
>Priority: Low
> Fix For: 5.x
>
> Attachments: Screenshot 2023-12-04 at 00.38.16.png, Screenshot
> 2023-12-09 at 16.58.25.png, signature.asc, test_output.txt,
> test_output_old.txt
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> *Updated* Jan 17 2024 after dev discussion
> Change CQLSH to left-align text while continue to right-align numbers. This
> will match how Postgres shell and Excel treat alignment of text and number.
> -
> *Original*
> We need to make this
> [https://github.com/apache/cassandra/blob/trunk/pylib/cqlshlib/cqlshmain.py#L1101]
> configurable so values in columns are either all on left or on right side of
> the column (basically change col.rjust to col.ljust).
> By default, it would be like it is now but there would be configuration
> property in cqlsh for that as well as a corresponding CQLSH command
> (optional), something like
> {code:java}
> ALIGNMENT LEFT|RIGHT
> {code}
> cc [~bschoeni]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-19671) Nodetool tabestats: add keyspace space used and table r/w ratio
[
https://issues.apache.org/jira/browse/CASSANDRA-19671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17851519#comment-17851519
]
Arun Ganesh edited comment on CASSANDRA-19671 at 6/3/24 4:58 AM:
-
[~bschoeni],
For the keyspace space-used metric, is it just a sum of the space-used values
of all the tables under it?
And, I already see a {{localReadWriteRatio}} for the tables in
{{StatsTable.java}}. Do you mean something else?
{code:java}
...
Speculative retries: 0
Local read count: 2
Local read latency: 8.774 ms
Local write count: 1
Local write latency: 2.759 ms
Local read/write ratio: 2.000
Pending flushes: 0
Percent repaired: 0.0
Bytes repaired: 0
Bytes unrepaired: 37
...
{code}
was (Author: JIRAUSER303038):
[~bschoeni],
For the keyspace space-used metric, is it just a sum of the space-used values
of all the tables under it?
And, I already see a {{localReadWriteRatio}} for the tables in
{{StatsTable.java}}. Do you mean something else?
{code:java}
...
Speculative retries: 0
Local read count: 2
Local read latency: 8.774 ms
Local write count: 1
Local write latency: 2.759 ms
{color:#FF8B00}Local read/write ratio: 2.000{color}
Pending flushes: 0
Percent repaired: 0.0
Bytes repaired: 0
Bytes unrepaired: 37
...
{code}
> Nodetool tabestats: add keyspace space used and table r/w ratio
> ---
>
> Key: CASSANDRA-19671
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19671
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Brad Schoening
>Priority: Normal
>
> Nodetool tabestats reports the space used live and total per table, but not
> for the entire keyspace. This would be useful information.
> Also, in the table level stats, it would be useful to have the read/write
> ratio. This metric is important in choosing compaction strategies such as
> LCS.
--
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-19671) Nodetool tabestats: add keyspace space used and table r/w ratio
[
https://issues.apache.org/jira/browse/CASSANDRA-19671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17851519#comment-17851519
]
Arun Ganesh commented on CASSANDRA-19671:
-
[~bschoeni],
For the keyspace space-used metric, is it just a sum of the space-used values
of all the tables under it?
And, I already see a {{localReadWriteRatio}} for the tables in
{{StatsTable.java}}. Do you mean something else?
{code:java}
...
Speculative retries: 0
Local read count: 2
Local read latency: 8.774 ms
Local write count: 1
Local write latency: 2.759 ms
{color:#FF8B00}Local read/write ratio: 2.000{color}
Pending flushes: 0
Percent repaired: 0.0
Bytes repaired: 0
Bytes unrepaired: 37
...
{code}
> Nodetool tabestats: add keyspace space used and table r/w ratio
> ---
>
> Key: CASSANDRA-19671
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19671
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Brad Schoening
>Priority: Normal
>
> Nodetool tabestats reports the space used live and total per table, but not
> for the entire keyspace. This would be useful information.
> Also, in the table level stats, it would be useful to have the read/write
> ratio. This metric is important in choosing compaction strategies such as
> LCS.
--
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-19671) Nodetool tabestats: add keyspace space used and table r/w ratio
[
https://issues.apache.org/jira/browse/CASSANDRA-19671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17852341#comment-17852341
]
Arun Ganesh commented on CASSANDRA-19671:
-
[~bschoeni], sure. I'll add them.
[~smiklosovic], when I was looking at the current unit-tests, I found
something. {{TableStatsPrinterTest::testDefaultHumanReadablePrinter}} doesn't
seem to be testing the human-readable formatting logic in its entirety. Some of
this formatting happens inside
[initializeKeyspaces()|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/tools/nodetool/stats/TableStatsHolder.java#L179],
and it is not called when we use a {{TestTableStatsHolder}} (see
[here|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/tools/nodetool/stats/TableStatsHolder.java#L55]).
I believe this has to do with how we store metrics when we retrieve them from
the probe: directly store them into StatsTable formatted as strings (like
{{[spaceUsedLive|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/tools/nodetool/stats/TableStatsHolder.java#L300]}})
vs keep them as numbers, format them when we print them (like
{{[bytesRepaired|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/tools/nodetool/stats/TableStatsPrinter.java#L125]}}).
> Nodetool tabestats: add keyspace space used and table r/w ratio
> ---
>
> Key: CASSANDRA-19671
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19671
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Brad Schoening
>Assignee: Arun Ganesh
>Priority: Low
> Attachments: plaintext-humanreadable.txt, plaintext.txt
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Nodetool tabestats reports the space used live and total per table, but not
> for the entire keyspace. This would be useful information.
> Also, in the table level stats, it would be useful to have the read/write
> ratio. This metric is important in choosing compaction strategies such as
> LCS.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17788) Add Cassandra to endoflife.date
[ https://issues.apache.org/jira/browse/CASSANDRA-17788?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arun Ganesh updated CASSANDRA-17788: Resolution: Fixed Status: Resolved (was: Triage Needed) > Add Cassandra to endoflife.date > --- > > Key: CASSANDRA-17788 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17788 > Project: Cassandra > Issue Type: Task > Components: Documentation >Reporter: Paulo Motta >Priority: Normal > Labels: lhf > > A few Apache projects are featured on [https://endoflife.date/] which is a > community-sourced tracker of end-of-life dates and support timelines: > * [zookeeper|https://endoflife.date/zookeeper] > * [solr|https://endoflife.date/solr] > Instructions on how to add a new project can be found on > [https://endoflife.date/contribute#new-adding-a-new-product] . > Cassandra EOL info can be found on > [https://cassandra.apache.org/_/download.html,] and possibly on dev mailing > list threads. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19583) Make 0 work as 0+unit for all three config classes (DataStorageSpec, DurationSpec, DataRateSpec)
[
https://issues.apache.org/jira/browse/CASSANDRA-19583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arun Ganesh updated CASSANDRA-19583:
Test and Documentation Plan: Added unit tests
Status: Patch Available (was: In Progress)
> Make 0 work as 0+unit for all three config classes (DataStorageSpec,
> DurationSpec, DataRateSpec)
>
>
> Key: CASSANDRA-19583
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19583
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Jon Haddad
>Assignee: Arun Ganesh
>Priority: Normal
> Fix For: 4.1.x, 5.0.x, 5.x
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The inline docs say:
> {noformat}
> Setting this to 0 disables throttling.
> {noformat}
> However, on startup, we throw this error:
> {noformat}
> Caused by: java.lang.IllegalArgumentException: Invalid data rate: 0 Accepted
> units: MiB/s, KiB/s, B/s where case matters and only non-negative values a>
> Apr 23 23:12:01 cassandra0 cassandra[3424]: at
> org.apache.cassandra.config.DataRateSpec.(DataRateSpec.java:52)
> Apr 23 23:12:01 cassandra0 cassandra[3424]: at
> org.apache.cassandra.config.DataRateSpec.(DataRateSpec.java:61)
> Apr 23 23:12:01 cassandra0 cassandra[3424]: at
> org.apache.cassandra.config.DataRateSpec$LongBytesPerSecondBound.(DataRateSpec.java:232)
> Apr 23 23:12:01 cassandra0 cassandra[3424]: ... 27 common frames
> omitted
> {noformat}
> We should allow 0 without a unit attached for data, duration, and data spec
> config parameters, as 0 is always 0 no matter the unit.
--
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-19583) Make 0 work as 0+unit for all three config classes (DataStorageSpec, DurationSpec, DataRateSpec)
[
https://issues.apache.org/jira/browse/CASSANDRA-19583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17854533#comment-17854533
]
Arun Ganesh commented on CASSANDRA-19583:
-
{quote}should I add more tests{quote}
I've added a few more unit tests after the initial patch last month. Are these
enough?
> Make 0 work as 0+unit for all three config classes (DataStorageSpec,
> DurationSpec, DataRateSpec)
>
>
> Key: CASSANDRA-19583
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19583
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Jon Haddad
>Assignee: Arun Ganesh
>Priority: Normal
> Fix For: 4.1.x, 5.0.x, 5.x
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The inline docs say:
> {noformat}
> Setting this to 0 disables throttling.
> {noformat}
> However, on startup, we throw this error:
> {noformat}
> Caused by: java.lang.IllegalArgumentException: Invalid data rate: 0 Accepted
> units: MiB/s, KiB/s, B/s where case matters and only non-negative values a>
> Apr 23 23:12:01 cassandra0 cassandra[3424]: at
> org.apache.cassandra.config.DataRateSpec.(DataRateSpec.java:52)
> Apr 23 23:12:01 cassandra0 cassandra[3424]: at
> org.apache.cassandra.config.DataRateSpec.(DataRateSpec.java:61)
> Apr 23 23:12:01 cassandra0 cassandra[3424]: at
> org.apache.cassandra.config.DataRateSpec$LongBytesPerSecondBound.(DataRateSpec.java:232)
> Apr 23 23:12:01 cassandra0 cassandra[3424]: ... 27 common frames
> omitted
> {noformat}
> We should allow 0 without a unit attached for data, duration, and data spec
> config parameters, as 0 is always 0 no matter the unit.
--
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
