[jira] [Commented] (CASSANDRA-10733) Inconsistencies in CQLSH auto-complete
[
https://issues.apache.org/jira/browse/CASSANDRA-10733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15123112#comment-15123112
]
Michael Edge commented on CASSANDRA-10733:
--
OK - I've added tests and test data to cover both issues raised in this JIRA
> Inconsistencies in CQLSH auto-complete
> --
>
> Key: CASSANDRA-10733
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10733
> Project: Cassandra
> Issue Type: Bug
> Components: CQL, Tools
>Reporter: Michael Edge
>Assignee: Michael Edge
>Priority: Trivial
> Labels: cqlsh, lhf
> Fix For: 2.2.x, 3.x
>
> Attachments: 10733-fix-space-2.2.txt,
> CASSANDRA-2.2-10733-CQLSH-Auto.patch, CASSANDRA-2.2-10733-tests.patch,
> CASSANDRA-3.0-10733-CQLSH-Auto.patch
>
>
> Auto-complete in cqlsh does not work correctly on some commands. We see some
> inconsistent behaviour when completing part of the statement and hitting the
> tab key.
> {color:green}Works correctly{color}
> Auto-complete on {{'desc table '}}, {{'desc function '}} and {{'desc type '}}
> works correctly. We see a list of all tables (or functions, types) in the
> current keyspace plus a list of all available keyspaces followed by a full
> stop (e.g. system.)
> {code}
> cqlsh:fxaggr> desc TABLE
> minutedata system_distributed.
> ;rawtickdatabylp system_traces.
> rawtickdatabysymbol tickdata
> daydata system.
> fxaggr. system_auth.
> {code}
> {color:red}Fix required{color}
> {{'desc aggregate '}} displays the aggregates in the current keyspace (in
> this case, only 1, called 'average') but does not display a list of available
> keyspaces. It only displays the current keyspace, with no following full stop.
> {code}
> cqlsh:fxaggr> desc aggregate
> ; average fxaggr
> {code}
> {color:green}Works correctly{color}
> Auto-complete on {{'desc table . '}} and {{'desc type
> .'}} works correctly. We see a list of all tables (or types) in the
> current keyspace
> {code}
> cqlsh:fxaggr> desc table fxaggr.
> daydata rawtickdatabylp tickdata
> minutedata rawtickdatabysymbol
> {code}
> {color:red}Fix required{color}
> Auto-complete on {{'desc function . '}} and {{'desc aggregate
> .'}} works inconsistently. In a keyspace with 2 functions, both
> beginning with the letters 'avg', if I type {{'desc function '}}
> and hit tab, auto-complete will result in this: {{'desc function fxaggr.avg
> '}} and will not display the matching functions. If I type {{'desc function
> .'}} (note the trailing full stop) and hit tab, auto-complete will
> work correctly:
> {code}
> cqlsh:fxaggr> desc function fxaggr.avg
> avgfinal avgstate
> {code}
> If I type {{'desc aggregate '}} and hit tab, auto-complete returns
> {{'desc aggregate '}} (it adds a space) and does not show me the
> list of available aggregates. If I type {{'desc aggregate .'}}
> (note the trailing full stop) and hit tab, auto-complete will work correctly.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10733) Inconsistencies in CQLSH auto-complete
[
https://issues.apache.org/jira/browse/CASSANDRA-10733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Edge updated CASSANDRA-10733:
-
Attachment: CASSANDRA-2.2-10733-tests.patch
> Inconsistencies in CQLSH auto-complete
> --
>
> Key: CASSANDRA-10733
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10733
> Project: Cassandra
> Issue Type: Bug
> Components: CQL, Tools
>Reporter: Michael Edge
>Assignee: Michael Edge
>Priority: Trivial
> Labels: cqlsh, lhf
> Fix For: 2.2.x, 3.x
>
> Attachments: 10733-fix-space-2.2.txt,
> CASSANDRA-2.2-10733-CQLSH-Auto.patch, CASSANDRA-2.2-10733-tests.patch,
> CASSANDRA-3.0-10733-CQLSH-Auto.patch
>
>
> Auto-complete in cqlsh does not work correctly on some commands. We see some
> inconsistent behaviour when completing part of the statement and hitting the
> tab key.
> {color:green}Works correctly{color}
> Auto-complete on {{'desc table '}}, {{'desc function '}} and {{'desc type '}}
> works correctly. We see a list of all tables (or functions, types) in the
> current keyspace plus a list of all available keyspaces followed by a full
> stop (e.g. system.)
> {code}
> cqlsh:fxaggr> desc TABLE
> minutedata system_distributed.
> ;rawtickdatabylp system_traces.
> rawtickdatabysymbol tickdata
> daydata system.
> fxaggr. system_auth.
> {code}
> {color:red}Fix required{color}
> {{'desc aggregate '}} displays the aggregates in the current keyspace (in
> this case, only 1, called 'average') but does not display a list of available
> keyspaces. It only displays the current keyspace, with no following full stop.
> {code}
> cqlsh:fxaggr> desc aggregate
> ; average fxaggr
> {code}
> {color:green}Works correctly{color}
> Auto-complete on {{'desc table . '}} and {{'desc type
> .'}} works correctly. We see a list of all tables (or types) in the
> current keyspace
> {code}
> cqlsh:fxaggr> desc table fxaggr.
> daydata rawtickdatabylp tickdata
> minutedata rawtickdatabysymbol
> {code}
> {color:red}Fix required{color}
> Auto-complete on {{'desc function . '}} and {{'desc aggregate
> .'}} works inconsistently. In a keyspace with 2 functions, both
> beginning with the letters 'avg', if I type {{'desc function '}}
> and hit tab, auto-complete will result in this: {{'desc function fxaggr.avg
> '}} and will not display the matching functions. If I type {{'desc function
> .'}} (note the trailing full stop) and hit tab, auto-complete will
> work correctly:
> {code}
> cqlsh:fxaggr> desc function fxaggr.avg
> avgfinal avgstate
> {code}
> If I type {{'desc aggregate '}} and hit tab, auto-complete returns
> {{'desc aggregate '}} (it adds a space) and does not show me the
> list of available aggregates. If I type {{'desc aggregate .'}}
> (note the trailing full stop) and hit tab, auto-complete will work correctly.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10733) Inconsistencies in CQLSH auto-complete
[
https://issues.apache.org/jira/browse/CASSANDRA-10733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Edge updated CASSANDRA-10733:
-
Attachment: (was: CASSANDRA-2.2-10733-added-tests-for-describe.patch)
> Inconsistencies in CQLSH auto-complete
> --
>
> Key: CASSANDRA-10733
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10733
> Project: Cassandra
> Issue Type: Bug
> Components: CQL, Tools
>Reporter: Michael Edge
>Assignee: Michael Edge
>Priority: Trivial
> Labels: cqlsh, lhf
> Fix For: 2.2.x, 3.x
>
> Attachments: 10733-fix-space-2.2.txt,
> CASSANDRA-2.2-10733-CQLSH-Auto.patch, CASSANDRA-3.0-10733-CQLSH-Auto.patch
>
>
> Auto-complete in cqlsh does not work correctly on some commands. We see some
> inconsistent behaviour when completing part of the statement and hitting the
> tab key.
> {color:green}Works correctly{color}
> Auto-complete on {{'desc table '}}, {{'desc function '}} and {{'desc type '}}
> works correctly. We see a list of all tables (or functions, types) in the
> current keyspace plus a list of all available keyspaces followed by a full
> stop (e.g. system.)
> {code}
> cqlsh:fxaggr> desc TABLE
> minutedata system_distributed.
> ;rawtickdatabylp system_traces.
> rawtickdatabysymbol tickdata
> daydata system.
> fxaggr. system_auth.
> {code}
> {color:red}Fix required{color}
> {{'desc aggregate '}} displays the aggregates in the current keyspace (in
> this case, only 1, called 'average') but does not display a list of available
> keyspaces. It only displays the current keyspace, with no following full stop.
> {code}
> cqlsh:fxaggr> desc aggregate
> ; average fxaggr
> {code}
> {color:green}Works correctly{color}
> Auto-complete on {{'desc table . '}} and {{'desc type
> .'}} works correctly. We see a list of all tables (or types) in the
> current keyspace
> {code}
> cqlsh:fxaggr> desc table fxaggr.
> daydata rawtickdatabylp tickdata
> minutedata rawtickdatabysymbol
> {code}
> {color:red}Fix required{color}
> Auto-complete on {{'desc function . '}} and {{'desc aggregate
> .'}} works inconsistently. In a keyspace with 2 functions, both
> beginning with the letters 'avg', if I type {{'desc function '}}
> and hit tab, auto-complete will result in this: {{'desc function fxaggr.avg
> '}} and will not display the matching functions. If I type {{'desc function
> .'}} (note the trailing full stop) and hit tab, auto-complete will
> work correctly:
> {code}
> cqlsh:fxaggr> desc function fxaggr.avg
> avgfinal avgstate
> {code}
> If I type {{'desc aggregate '}} and hit tab, auto-complete returns
> {{'desc aggregate '}} (it adds a space) and does not show me the
> list of available aggregates. If I type {{'desc aggregate .'}}
> (note the trailing full stop) and hit tab, auto-complete will work correctly.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10733) Inconsistencies in CQLSH auto-complete
[
https://issues.apache.org/jira/browse/CASSANDRA-10733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15121733#comment-15121733
]
Michael Edge commented on CASSANDRA-10733:
--
[~thobbs] my apologies, I missed your earlier comment.
I've added a test for the first of the issues above - please see attached
patch. I should hopefully have some time to add tests for the second issue
tomorrow.
> Inconsistencies in CQLSH auto-complete
> --
>
> Key: CASSANDRA-10733
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10733
> Project: Cassandra
> Issue Type: Bug
> Components: CQL, Tools
>Reporter: Michael Edge
>Assignee: Michael Edge
>Priority: Trivial
> Labels: cqlsh, lhf
> Fix For: 2.2.x, 3.x
>
> Attachments: 10733-fix-space-2.2.txt,
> CASSANDRA-2.2-10733-CQLSH-Auto.patch,
> CASSANDRA-2.2-10733-added-tests-for-describe.patch,
> CASSANDRA-3.0-10733-CQLSH-Auto.patch
>
>
> Auto-complete in cqlsh does not work correctly on some commands. We see some
> inconsistent behaviour when completing part of the statement and hitting the
> tab key.
> {color:green}Works correctly{color}
> Auto-complete on {{'desc table '}}, {{'desc function '}} and {{'desc type '}}
> works correctly. We see a list of all tables (or functions, types) in the
> current keyspace plus a list of all available keyspaces followed by a full
> stop (e.g. system.)
> {code}
> cqlsh:fxaggr> desc TABLE
> minutedata system_distributed.
> ;rawtickdatabylp system_traces.
> rawtickdatabysymbol tickdata
> daydata system.
> fxaggr. system_auth.
> {code}
> {color:red}Fix required{color}
> {{'desc aggregate '}} displays the aggregates in the current keyspace (in
> this case, only 1, called 'average') but does not display a list of available
> keyspaces. It only displays the current keyspace, with no following full stop.
> {code}
> cqlsh:fxaggr> desc aggregate
> ; average fxaggr
> {code}
> {color:green}Works correctly{color}
> Auto-complete on {{'desc table . '}} and {{'desc type
> .'}} works correctly. We see a list of all tables (or types) in the
> current keyspace
> {code}
> cqlsh:fxaggr> desc table fxaggr.
> daydata rawtickdatabylp tickdata
> minutedata rawtickdatabysymbol
> {code}
> {color:red}Fix required{color}
> Auto-complete on {{'desc function . '}} and {{'desc aggregate
> .'}} works inconsistently. In a keyspace with 2 functions, both
> beginning with the letters 'avg', if I type {{'desc function '}}
> and hit tab, auto-complete will result in this: {{'desc function fxaggr.avg
> '}} and will not display the matching functions. If I type {{'desc function
> .'}} (note the trailing full stop) and hit tab, auto-complete will
> work correctly:
> {code}
> cqlsh:fxaggr> desc function fxaggr.avg
> avgfinal avgstate
> {code}
> If I type {{'desc aggregate '}} and hit tab, auto-complete returns
> {{'desc aggregate '}} (it adds a space) and does not show me the
> list of available aggregates. If I type {{'desc aggregate .'}}
> (note the trailing full stop) and hit tab, auto-complete will work correctly.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10733) Inconsistencies in CQLSH auto-complete
[
https://issues.apache.org/jira/browse/CASSANDRA-10733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Edge updated CASSANDRA-10733:
-
Attachment: CASSANDRA-2.2-10733-added-tests-for-describe.patch
> Inconsistencies in CQLSH auto-complete
> --
>
> Key: CASSANDRA-10733
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10733
> Project: Cassandra
> Issue Type: Bug
> Components: CQL, Tools
>Reporter: Michael Edge
>Assignee: Michael Edge
>Priority: Trivial
> Labels: cqlsh, lhf
> Fix For: 2.2.x, 3.x
>
> Attachments: 10733-fix-space-2.2.txt,
> CASSANDRA-2.2-10733-CQLSH-Auto.patch,
> CASSANDRA-2.2-10733-added-tests-for-describe.patch,
> CASSANDRA-3.0-10733-CQLSH-Auto.patch
>
>
> Auto-complete in cqlsh does not work correctly on some commands. We see some
> inconsistent behaviour when completing part of the statement and hitting the
> tab key.
> {color:green}Works correctly{color}
> Auto-complete on {{'desc table '}}, {{'desc function '}} and {{'desc type '}}
> works correctly. We see a list of all tables (or functions, types) in the
> current keyspace plus a list of all available keyspaces followed by a full
> stop (e.g. system.)
> {code}
> cqlsh:fxaggr> desc TABLE
> minutedata system_distributed.
> ;rawtickdatabylp system_traces.
> rawtickdatabysymbol tickdata
> daydata system.
> fxaggr. system_auth.
> {code}
> {color:red}Fix required{color}
> {{'desc aggregate '}} displays the aggregates in the current keyspace (in
> this case, only 1, called 'average') but does not display a list of available
> keyspaces. It only displays the current keyspace, with no following full stop.
> {code}
> cqlsh:fxaggr> desc aggregate
> ; average fxaggr
> {code}
> {color:green}Works correctly{color}
> Auto-complete on {{'desc table . '}} and {{'desc type
> .'}} works correctly. We see a list of all tables (or types) in the
> current keyspace
> {code}
> cqlsh:fxaggr> desc table fxaggr.
> daydata rawtickdatabylp tickdata
> minutedata rawtickdatabysymbol
> {code}
> {color:red}Fix required{color}
> Auto-complete on {{'desc function . '}} and {{'desc aggregate
> .'}} works inconsistently. In a keyspace with 2 functions, both
> beginning with the letters 'avg', if I type {{'desc function '}}
> and hit tab, auto-complete will result in this: {{'desc function fxaggr.avg
> '}} and will not display the matching functions. If I type {{'desc function
> .'}} (note the trailing full stop) and hit tab, auto-complete will
> work correctly:
> {code}
> cqlsh:fxaggr> desc function fxaggr.avg
> avgfinal avgstate
> {code}
> If I type {{'desc aggregate '}} and hit tab, auto-complete returns
> {{'desc aggregate '}} (it adds a space) and does not show me the
> list of available aggregates. If I type {{'desc aggregate .'}}
> (note the trailing full stop) and hit tab, auto-complete will work correctly.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10719) Inconsistencies within CQL 'describe', and CQL docs/'help describe'
[ https://issues.apache.org/jira/browse/CASSANDRA-10719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15046128#comment-15046128 ] Michael Edge commented on CASSANDRA-10719: -- [~lor...@datastax.com] - I notice the 'DESCRIBE' docs at http://docs.datastax.com/en/cql/3.3/cql/cql_reference/describe_r1.html still need updating to align with the MS-Word document I sent you earlier. Otherwise they'll be incorrect and won't match the cqlsh DESCRIBE output. > Inconsistencies within CQL 'describe', and CQL docs/'help describe' > --- > > Key: CASSANDRA-10719 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10719 > Project: Cassandra > Issue Type: Improvement > Components: CQL, Documentation and Website, Tools >Reporter: Michael Edge >Assignee: Michael Edge >Priority: Minor > Labels: cqlsh, doc-impacting, docs > Fix For: 2.1.12, 2.2.4, 3.0.1, 3.1 > > Attachments: CASSANDRA-2.1-10719-Describe.patch, > CASSANDRA-2.2-10719-Describe.patch, CASSANDRA-3.0-10719-Describe.patch > > > While investigating the issue CASSANDRA-9678 I noticed a number of > inconsistencies in the way 'describe' operates, so I'm opening a new issue to > address these. This issue will also address CASSANDRA-9678. > I'd be happy to work on this. > There are a number of inconsistencies in the way 'describe' operates within > cqlsh, and also in the 'help describe' description within cqlsh compared to > the CQL documentation (at > http://docs.datastax.com/en/cql/3.3/cql/cql_reference/describe_r1.html) > For example, 'desc functions' will list all functions for all keyspaces > regardless of whether there is a current keyspace or not, whereas 'desc > tables' or 'desc types' will list only the tables or types for the current > keyspace. > Some commands exist in cqlsh that are not in the CQL documentation, nor in > the 'help describe' description. For example, 'desc functions' is a valid > CQLSH command but does not appear in either the CQL docs or 'help describe'. > I suggest we align the way the 'describe' command works so that it works > consistently regardless of whether it is describing a table, type, function > or any other database object, and also update the CQL and 'help describe' > docs to match. Since 'describe tables' and it's variants has been around the > longest we should probably align other 'describe' commands to 'describe > tables'. > My preliminary analysis has shown at least the following inconsistencies: > - 'desc functions' (with current keyspace), differs from 'desc tables' and > 'desc types'. > - a number of commands are missing from the CQL docs or 'help describe, such > as: desc table ., desc functions (no current keyspace), > desc function , desc type ., etc. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10725) Stress gives "Unknown keyspace" error when a map type is used in user profile
[
https://issues.apache.org/jira/browse/CASSANDRA-10725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Edge updated CASSANDRA-10725:
-
Fix Version/s: 2.2.x
> Stress gives "Unknown keyspace" error when a map type is used in user profile
> -
>
> Key: CASSANDRA-10725
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10725
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
>Reporter: Sebastian Estevez
>Assignee: Michael Edge
>Priority: Minor
> Labels: stress, tools
> Fix For: 2.2.x, 3.x
>
> Attachments: CASSANDRA-3.0-10725-Cassandra-Stress.patch
>
>
> Steps to reproduce:
> copy the following stress.yaml:
> {code}# Keyspace Name
> keyspace: autogeneratedtest
>
> # The CQL for creating a keyspace (optional if it already exists)
> keyspace_definition: |
> CREATE KEYSPACE autogeneratedtest WITH replication = {'class':
> 'SimpleStrategy', 'replication_factor': 1};
>
> # Table name
> table: smartcity_data
>
> # The CQL for creating a table you wish to stress (optional if it already
> exists)
> table_definition:
> CREATE TABLE smartcity_data (
> device text,
> reporter text,
> time timestamp,
> data_ map,
> metadata_ text,
> solr_query text,
> timeack timestamp,
> timefalse timestamp,
> timeresolved timestamp,
> PRIMARY KEY (device, reporter, time)
> )
> ### Column Distribution Specifications ###
>
> columnspec:
> - name: device
> size: fixed(10)
> population: uniform(1..10)
>
> - name: reporter
> size: fixed(10)
> population: uniform(1..10)
>
> - name: time
> size: fixed(10)
> population: uniform(1..10)
>
> - name: data_
> size: fixed(10)
> population: uniform(1..10)
>
> - name: metadata_
> size: fixed(10)
> population: uniform(1..10)
>
> - name: solr_query
> size: fixed(10)
> population: uniform(1..10)
>
> - name: timeack
> size: fixed(10)
> population: uniform(1..10)
>
> - name: timefalse
> size: fixed(10)
> population: uniform(1..10)
>
> - name: timeresolved
> size: fixed(10)
> population: uniform(1..10)
>
>
> ### Batch Ratio Distribution Specifications ###
>
> insert:
> partitions: fixed(1)# Our partition key is the domain so only
> insert one per batch
>
> select: fixed(1)/1000# We have 1000 posts per domain so 1/1000
> will allow 1 post per batch
>
> batchtype: UNLOGGED # Unlogged batches
>
>
> #
> # A list of queries you wish to run against the schema
> #
> queries:
>likelyquery0:
> cql: Select * from smartcity_data where device = ?
> fields: samerow
>likelyquery1:
> cql: Select * from smartcity_data where device = ? and reporter = ?
> fields: samerow
>likelyquery2:
> cql: Select * from smartcity_data where device = ? and reporter = ? and
> time = ?
> fields: samerow{code}
> and run:
> {code}cassandra-stress user profile=stress.yaml ops\(insert=1\) n=10 -rate
> threads=1
> There was a problem parsing the table cql: Unknown keyspace
> autogeneratedtest{code}
> You'll see the following error:
> {quote}
> There was a problem parsing the table cql: Unknown keyspace autogeneratedtest
> {quote}
> The error should instead state:
> {quote}Maps are not currently supported in cassandra-stress{quote}
> If you replace `data_ map`, with `data_ text` it works fine.
> Related: CASSANDRA-9091
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-10725) Stress gives "Unknown keyspace" error when a map type is used in user profile
[
https://issues.apache.org/jira/browse/CASSANDRA-10725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15029428#comment-15029428
]
Michael Edge edited comment on CASSANDRA-10725 at 11/27/15 6:20 AM:
{color:red}Note: no need to apply patch to {{v2.1}}. {color}
Applying the patch has the following benefits:
* {{v3.0}}: the NPE no longer occurs and the error message returned to the user
states that a MAP is not supported in cassandra-stress
* {{v2.2}}: the NPE no longer occurs. However, the error message returned to
the user is vague and does not mention the MAP type that caused the issue
* {{v2.1}}: no benefit
For versions 2.1 and 2.2 the root exception thrown from CFMetaData and CQL3Type
does not provide any useful information regarding data types, unlike the v3.0
root exception. Considering this is a minor issue I don't think it's worthwhile
changing those classes to provide a more informative exception - this has
already been taken care of in v3.x.
In v3.0, the root exception is:
{code}
org.apache.cassandra.exceptions.InvalidRequestException: Unknown type
autogeneratedtest.map
at
org.apache.cassandra.cql3.CQL3Type$Raw$RawUT.prepare(CQL3Type.java:780)
at
org.apache.cassandra.cql3.statements.CreateTableStatement$RawStatement.prepare(CreateTableStatement.java:225)
at org.apache.cassandra.config.CFMetaData.compile(CFMetaData.java:408)
{code}
whereas in v2.1 and v2.2 the root exception is:
{code}
java.lang.RuntimeException:
org.apache.cassandra.exceptions.InvalidRequestException: Unknown keyspace
autogeneratedtest
at org.apache.cassandra.config.CFMetaData.compile(CFMetaData.java:537)
{code}
was (Author: michaeledge):
{color:red}Note: no need to apply patch to {{v2.1}}. {color}
Applying the patch has the following benefits:
v3.0: the NPE no longer occurs and the error message returned to the user
states that a MAP is not supported in cassandra-stress
v2.2: the NPE no longer occurs. However, the error message returned to the user
is vague and does not mention the MAP type that caused the issue
v2.1: no benefit
For versions 2.1 and 2.2 the root exception thrown from CFMetaData and CQL3Type
does not provide any useful information regarding data types, unlike the v3.0
root exception. Considering this is a minor issue I don't think it's worthwhile
changing those classes to provide a more informative exception - this has
already been taken care of in v3.x.
In v3.0, the root exception is:
{code}
org.apache.cassandra.exceptions.InvalidRequestException: Unknown type
autogeneratedtest.map
at
org.apache.cassandra.cql3.CQL3Type$Raw$RawUT.prepare(CQL3Type.java:780)
at
org.apache.cassandra.cql3.statements.CreateTableStatement$RawStatement.prepare(CreateTableStatement.java:225)
at org.apache.cassandra.config.CFMetaData.compile(CFMetaData.java:408)
{code}
whereas in v2.1 and v2.2 the root exception is:
{code}
java.lang.RuntimeException:
org.apache.cassandra.exceptions.InvalidRequestException: Unknown keyspace
autogeneratedtest
at org.apache.cassandra.config.CFMetaData.compile(CFMetaData.java:537)
{code}
> Stress gives "Unknown keyspace" error when a map type is used in user profile
> -
>
> Key: CASSANDRA-10725
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10725
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
>Reporter: Sebastian Estevez
>Assignee: Michael Edge
>Priority: Minor
> Labels: stress, tools
> Fix For: 3.x
>
> Attachments: CASSANDRA-3.0-10725-Cassandra-Stress.patch
>
>
> Steps to reproduce:
> copy the following stress.yaml:
> {code}# Keyspace Name
> keyspace: autogeneratedtest
>
> # The CQL for creating a keyspace (optional if it already exists)
> keyspace_definition: |
> CREATE KEYSPACE autogeneratedtest WITH replication = {'class':
> 'SimpleStrategy', 'replication_factor': 1};
>
> # Table name
> table: smartcity_data
>
> # The CQL for creating a table you wish to stress (optional if it already
> exists)
> table_definition:
> CREATE TABLE smartcity_data (
> device text,
> reporter text,
> time timestamp,
> data_ map,
> metadata_ text,
> solr_query text,
> timeack timestamp,
> timefalse timestamp,
> timeresolved timestamp,
> PRIMARY KEY (device, reporter, time)
> )
> ### Column Distribution Specifications ###
>
> columnspec:
> - name: device
> size: fixed(10)
> population: uniform(1..10)
>
> - name: reporter
> size: fixed(10)
> population: uniform(1..10)
>
> - name: time
> size: fixed(10)
> population: uniform(1..10)
>
> - name: data_
> size: fixed(10)
> population: uniform(1..10)
>
> - name: metadata_
>
[jira] [Comment Edited] (CASSANDRA-10725) Stress gives "Unknown keyspace" error when a map type is used in user profile
[
https://issues.apache.org/jira/browse/CASSANDRA-10725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15029428#comment-15029428
]
Michael Edge edited comment on CASSANDRA-10725 at 11/27/15 6:20 AM:
{color:red}Note: no need to apply patch to {{v2.1}}. {color}
Applying the patch has the following benefits:
v3.0: the NPE no longer occurs and the error message returned to the user
states that a MAP is not supported in cassandra-stress
v2.2: the NPE no longer occurs. However, the error message returned to the user
is vague and does not mention the MAP type that caused the issue
v2.1: no benefit
For versions 2.1 and 2.2 the root exception thrown from CFMetaData and CQL3Type
does not provide any useful information regarding data types, unlike the v3.0
root exception. Considering this is a minor issue I don't think it's worthwhile
changing those classes to provide a more informative exception - this has
already been taken care of in v3.x.
In v3.0, the root exception is:
{code}
org.apache.cassandra.exceptions.InvalidRequestException: Unknown type
autogeneratedtest.map
at
org.apache.cassandra.cql3.CQL3Type$Raw$RawUT.prepare(CQL3Type.java:780)
at
org.apache.cassandra.cql3.statements.CreateTableStatement$RawStatement.prepare(CreateTableStatement.java:225)
at org.apache.cassandra.config.CFMetaData.compile(CFMetaData.java:408)
{code}
whereas in v2.1 and v2.2 the root exception is:
{code}
java.lang.RuntimeException:
org.apache.cassandra.exceptions.InvalidRequestException: Unknown keyspace
autogeneratedtest
at org.apache.cassandra.config.CFMetaData.compile(CFMetaData.java:537)
{code}
was (Author: michaeledge):
{color:red}Note: patch CANNOT be applied to {{v2.1}} or {{v2.2}}. {color}
For these versions the root exception thrown from CFMetaData and CQL3Type does
not provide any useful information regarding data types, unlike the v3.0 root
exception. Considering this is a minor issue I don't think it's worthwhile
changing those classes to provide a more informative exception - this has
already been taken care of in v3.x.
In v3.0, the root exception is:
{code}
org.apache.cassandra.exceptions.InvalidRequestException: Unknown type
autogeneratedtest.map
at
org.apache.cassandra.cql3.CQL3Type$Raw$RawUT.prepare(CQL3Type.java:780)
at
org.apache.cassandra.cql3.statements.CreateTableStatement$RawStatement.prepare(CreateTableStatement.java:225)
at org.apache.cassandra.config.CFMetaData.compile(CFMetaData.java:408)
{code}
whereas in v2.1 and v2.2 the root exception is:
{code}
java.lang.RuntimeException:
org.apache.cassandra.exceptions.InvalidRequestException: Unknown keyspace
autogeneratedtest
at org.apache.cassandra.config.CFMetaData.compile(CFMetaData.java:537)
{code}
> Stress gives "Unknown keyspace" error when a map type is used in user profile
> -
>
> Key: CASSANDRA-10725
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10725
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
>Reporter: Sebastian Estevez
>Assignee: Michael Edge
>Priority: Minor
> Labels: stress, tools
> Fix For: 3.x
>
> Attachments: CASSANDRA-3.0-10725-Cassandra-Stress.patch
>
>
> Steps to reproduce:
> copy the following stress.yaml:
> {code}# Keyspace Name
> keyspace: autogeneratedtest
>
> # The CQL for creating a keyspace (optional if it already exists)
> keyspace_definition: |
> CREATE KEYSPACE autogeneratedtest WITH replication = {'class':
> 'SimpleStrategy', 'replication_factor': 1};
>
> # Table name
> table: smartcity_data
>
> # The CQL for creating a table you wish to stress (optional if it already
> exists)
> table_definition:
> CREATE TABLE smartcity_data (
> device text,
> reporter text,
> time timestamp,
> data_ map,
> metadata_ text,
> solr_query text,
> timeack timestamp,
> timefalse timestamp,
> timeresolved timestamp,
> PRIMARY KEY (device, reporter, time)
> )
> ### Column Distribution Specifications ###
>
> columnspec:
> - name: device
> size: fixed(10)
> population: uniform(1..10)
>
> - name: reporter
> size: fixed(10)
> population: uniform(1..10)
>
> - name: time
> size: fixed(10)
> population: uniform(1..10)
>
> - name: data_
> size: fixed(10)
> population: uniform(1..10)
>
> - name: metadata_
> size: fixed(10)
> population: uniform(1..10)
>
> - name: solr_query
> size: fixed(10)
> population: uniform(1..10)
>
> - name: timeack
> size: fixed(10)
> population: uniform(1..10)
>
> - name: timefalse
> size: fixed(10)
> population: uniform(1..10)
>
> - name: timeresolved
> size: fixed(10)
>
[jira] [Comment Edited] (CASSANDRA-10725) Stress gives "Unknown keyspace" error when a map type is used in user profile
[
https://issues.apache.org/jira/browse/CASSANDRA-10725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15029430#comment-15029430
]
Michael Edge edited comment on CASSANDRA-10725 at 11/27/15 6:16 AM:
Patch for v2.2x and v3.x only
was (Author: michaeledge):
Patch for v3.x only
> Stress gives "Unknown keyspace" error when a map type is used in user profile
> -
>
> Key: CASSANDRA-10725
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10725
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
>Reporter: Sebastian Estevez
>Assignee: Michael Edge
>Priority: Minor
> Labels: stress, tools
> Fix For: 3.x
>
> Attachments: CASSANDRA-3.0-10725-Cassandra-Stress.patch
>
>
> Steps to reproduce:
> copy the following stress.yaml:
> {code}# Keyspace Name
> keyspace: autogeneratedtest
>
> # The CQL for creating a keyspace (optional if it already exists)
> keyspace_definition: |
> CREATE KEYSPACE autogeneratedtest WITH replication = {'class':
> 'SimpleStrategy', 'replication_factor': 1};
>
> # Table name
> table: smartcity_data
>
> # The CQL for creating a table you wish to stress (optional if it already
> exists)
> table_definition:
> CREATE TABLE smartcity_data (
> device text,
> reporter text,
> time timestamp,
> data_ map,
> metadata_ text,
> solr_query text,
> timeack timestamp,
> timefalse timestamp,
> timeresolved timestamp,
> PRIMARY KEY (device, reporter, time)
> )
> ### Column Distribution Specifications ###
>
> columnspec:
> - name: device
> size: fixed(10)
> population: uniform(1..10)
>
> - name: reporter
> size: fixed(10)
> population: uniform(1..10)
>
> - name: time
> size: fixed(10)
> population: uniform(1..10)
>
> - name: data_
> size: fixed(10)
> population: uniform(1..10)
>
> - name: metadata_
> size: fixed(10)
> population: uniform(1..10)
>
> - name: solr_query
> size: fixed(10)
> population: uniform(1..10)
>
> - name: timeack
> size: fixed(10)
> population: uniform(1..10)
>
> - name: timefalse
> size: fixed(10)
> population: uniform(1..10)
>
> - name: timeresolved
> size: fixed(10)
> population: uniform(1..10)
>
>
> ### Batch Ratio Distribution Specifications ###
>
> insert:
> partitions: fixed(1)# Our partition key is the domain so only
> insert one per batch
>
> select: fixed(1)/1000# We have 1000 posts per domain so 1/1000
> will allow 1 post per batch
>
> batchtype: UNLOGGED # Unlogged batches
>
>
> #
> # A list of queries you wish to run against the schema
> #
> queries:
>likelyquery0:
> cql: Select * from smartcity_data where device = ?
> fields: samerow
>likelyquery1:
> cql: Select * from smartcity_data where device = ? and reporter = ?
> fields: samerow
>likelyquery2:
> cql: Select * from smartcity_data where device = ? and reporter = ? and
> time = ?
> fields: samerow{code}
> and run:
> {code}cassandra-stress user profile=stress.yaml ops\(insert=1\) n=10 -rate
> threads=1
> There was a problem parsing the table cql: Unknown keyspace
> autogeneratedtest{code}
> You'll see the following error:
> {quote}
> There was a problem parsing the table cql: Unknown keyspace autogeneratedtest
> {quote}
> The error should instead state:
> {quote}Maps are not currently supported in cassandra-stress{quote}
> If you replace `data_ map`, with `data_ text` it works fine.
> Related: CASSANDRA-9091
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-10725) Stress gives "Unknown keyspace" error when a map type is used in user profile
[
https://issues.apache.org/jira/browse/CASSANDRA-10725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15029360#comment-15029360
]
Michael Edge edited comment on CASSANDRA-10725 at 11/27/15 6:15 AM:
[~sebastian.este...@datastax.com], in which version did you discover this?
I tested against v2.1, 2.2 and 3.0 with the following results:
* v2.1: There was a problem parsing the table cql: Unknown keyspace
autogeneratedtest
* v2.2 and v3.0: NullPointerException
The piece of code causing the NPE is the same line of code that throws the
exception message seen in v2.1.
The exception is thrown by {{StressProfile.java}}, and the real root cause
exception depends on the Cassandra version:
{code}
v3.0
org.apache.cassandra.exceptions.InvalidRequestException: Unknown type
autogeneratedtest.map
{code}
{code}
v2.1 and v2.2
org.apache.cassandra.exceptions.InvalidRequestException: Unknown keyspace
autogeneratedtest
{code}
In v3.0 this exception is lost by the line of code in StressProfile.java that
re-throws the exception. Also, the NPE is thrown by {{e.getCause()}}
{code}
throw new IllegalArgumentException("There was a problem parsing the table cql:
" + e.getCause().getMessage());
{code}
I believe this line of code should be changed to:
{code}
throw new IllegalArgumentException("There was a problem parsing the table cql:
" + e.getMessage());
{code}
After making this change the following message appears:
{quote}v2.2: There was a problem parsing the table cql: Unknown keyspace
autogeneratedtest
{quote}
{quote}v3.0: There was a problem parsing the table cql: Unknown type
autogeneratedtest.map{quote}
Patch for v2.2 and v3.0 attached - this solves the NPE and also provides an
understandable error message in v3.0. There is no need to apply this patch to
v2.1 as it provides no benefit.
was (Author: michaeledge):
[~sebastian.este...@datastax.com], in which version did you discover this?
I tested against v2.1, 2.2 and 3.0 with the following results:
* v2.1: There was a problem parsing the table cql: Unknown keyspace
autogeneratedtest
* v2.2 and v3.0: NullPointerException
The piece of code causing the NPE is the same line of code that throws the
exception message seen in v2.1.
The exception is thrown by {{StressProfile.java}}, and the real root cause
exception depends on the Cassandra version:
{code}
v3.0
org.apache.cassandra.exceptions.InvalidRequestException: Unknown type
autogeneratedtest.map
{code}
{code}
v2.1 and v2.2
org.apache.cassandra.exceptions.InvalidRequestException: Unknown keyspace
autogeneratedtest
{code}
In v3.0 this exception is lost by the line of code in StressProfile.java that
re-throws the exception. Also, the NPE is thrown by {{e.getCause()}}
{code}
throw new IllegalArgumentException("There was a problem parsing the table cql:
" + e.getCause().getMessage());
{code}
I believe this line of code should be changed to:
{code}
throw new IllegalArgumentException("There was a problem parsing the table cql:
" + e.getMessage());
{code}
After making this change the following message appears:
{quote}v2.2: There was a problem parsing the table cql:
org.apache.cassandra.exceptions.InvalidRequestException: Unknown keyspace
autogeneratedtest
{quote}
{quote}v3.0: There was a problem parsing the table cql: Unknown type
autogeneratedtest.map{quote}
Patch for v2.2 and v3.0 attached - this solves the NPE and also provides an
understandable error message in v3.0. There is no need to apply this patch to
v2.1 as it provides no benefit.
> Stress gives "Unknown keyspace" error when a map type is used in user profile
> -
>
> Key: CASSANDRA-10725
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10725
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
>Reporter: Sebastian Estevez
>Assignee: Michael Edge
>Priority: Minor
> Labels: stress, tools
> Fix For: 3.x
>
> Attachments: CASSANDRA-3.0-10725-Cassandra-Stress.patch
>
>
> Steps to reproduce:
> copy the following stress.yaml:
> {code}# Keyspace Name
> keyspace: autogeneratedtest
>
> # The CQL for creating a keyspace (optional if it already exists)
> keyspace_definition: |
> CREATE KEYSPACE autogeneratedtest WITH replication = {'class':
> 'SimpleStrategy', 'replication_factor': 1};
>
> # Table name
> table: smartcity_data
>
> # The CQL for creating a table you wish to stress (optional if it already
> exists)
> table_definition:
> CREATE TABLE smartcity_data (
> device text,
> reporter text,
> time timestamp,
> data_ map,
> metadata_ text,
> solr_query text,
> timeack timestamp,
> timefalse timestamp,
> timeresolved timestamp,
> PRIMARY KEY (device, reporter, time)
> )
>
[jira] [Comment Edited] (CASSANDRA-10725) Stress gives "Unknown keyspace" error when a map type is used in user profile
[
https://issues.apache.org/jira/browse/CASSANDRA-10725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15029360#comment-15029360
]
Michael Edge edited comment on CASSANDRA-10725 at 11/27/15 6:12 AM:
[~sebastian.este...@datastax.com], in which version did you discover this?
I tested against v2.1, 2.2 and 3.0 with the following results:
* v2.1: There was a problem parsing the table cql: Unknown keyspace
autogeneratedtest
* v2.2 and v3.0: NullPointerException
The piece of code causing the NPE is the same line of code that throws the
exception message seen in v2.1.
The exception is thrown by {{StressProfile.java}}, and the real root cause
exception depends on the Cassandra version:
{code}
v3.0
org.apache.cassandra.exceptions.InvalidRequestException: Unknown type
autogeneratedtest.map
{code}
{code}
v2.1 and v2.2
org.apache.cassandra.exceptions.InvalidRequestException: Unknown keyspace
autogeneratedtest
{code}
In v3.0 this exception is lost by the line of code in StressProfile.java that
re-throws the exception. Also, the NPE is thrown by {{e.getCause()}}
{code}
throw new IllegalArgumentException("There was a problem parsing the table cql:
" + e.getCause().getMessage());
{code}
I believe this line of code should be changed to:
{code}
throw new IllegalArgumentException("There was a problem parsing the table cql:
" + e.getMessage());
{code}
After making this change the following message appears:
{quote}v2.2: There was a problem parsing the table cql:
org.apache.cassandra.exceptions.InvalidRequestException: Unknown keyspace
autogeneratedtest
{quote}
{quote}v3.0: There was a problem parsing the table cql: Unknown type
autogeneratedtest.map{quote}
Patch for v2.2 and v3.0 attached - this solves the NPE and also provides an
understandable error message in v3.0. There is no need to apply this patch to
v2.1 as it provides no benefit.
was (Author: michaeledge):
[~sebastian.este...@datastax.com], in which version did you discover this?
I tested against trunk and received a NullPointerException. However, the piece
of code causing the NPE is the same line of code that causes your {quote}There
was a problem parsing the table cql: Unknown keyspace autogeneratedtest{quote}
The exception is thrown by {{StressProfile.java}}, and the real underlying
exception is:
{code}
org.apache.cassandra.exceptions.InvalidRequestException: Unknown type
autogeneratedtest.map
{code}
This exception is lost by the line of code in StressProfile.java that throws
the exception. Also, the NPE is thrown by {{e.getCause()}}
{code}
throw new IllegalArgumentException("There was a problem parsing the table cql:
" + e.getCause().getMessage());
{code}
I believe this line of code should be changed to:
{code}
throw new IllegalArgumentException("There was a problem parsing the table cql:
" + e.getMessage());
{code}
After making this change the following message appears:
{quote}There was a problem parsing the table cql: Unknown type
autogeneratedtest.map{quote}
Patch for trunk attached.
> Stress gives "Unknown keyspace" error when a map type is used in user profile
> -
>
> Key: CASSANDRA-10725
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10725
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
>Reporter: Sebastian Estevez
>Assignee: Michael Edge
>Priority: Minor
> Labels: stress, tools
> Fix For: 3.x
>
> Attachments: CASSANDRA-3.0-10725-Cassandra-Stress.patch
>
>
> Steps to reproduce:
> copy the following stress.yaml:
> {code}# Keyspace Name
> keyspace: autogeneratedtest
>
> # The CQL for creating a keyspace (optional if it already exists)
> keyspace_definition: |
> CREATE KEYSPACE autogeneratedtest WITH replication = {'class':
> 'SimpleStrategy', 'replication_factor': 1};
>
> # Table name
> table: smartcity_data
>
> # The CQL for creating a table you wish to stress (optional if it already
> exists)
> table_definition:
> CREATE TABLE smartcity_data (
> device text,
> reporter text,
> time timestamp,
> data_ map,
> metadata_ text,
> solr_query text,
> timeack timestamp,
> timefalse timestamp,
> timeresolved timestamp,
> PRIMARY KEY (device, reporter, time)
> )
> ### Column Distribution Specifications ###
>
> columnspec:
> - name: device
> size: fixed(10)
> population: uniform(1..10)
>
> - name: reporter
> size: fixed(10)
> population: uniform(1..10)
>
> - name: time
> size: fixed(10)
> population: uniform(1..10)
>
> - name: data_
> size: fixed(10)
> population: uniform(1..10)
>
> - name: metadata_
> size: fixed(10)
> population: uniform(1..10)
>
> - name: solr_query
> size: fixed(10
[jira] [Comment Edited] (CASSANDRA-10725) Stress gives "Unknown keyspace" error when a map type is used in user profile
[
https://issues.apache.org/jira/browse/CASSANDRA-10725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15029428#comment-15029428
]
Michael Edge edited comment on CASSANDRA-10725 at 11/27/15 3:50 AM:
{color:red}Note: patch CANNOT be applied to {{v2.1}} or {{v2.2}}. {color}
For these versions the root exception thrown from CFMetaData and CQL3Type does
not provide any useful information regarding data types, unlike the v3.0 root
exception. Considering this is a minor issue I don't think it's worthwhile
changing those classes to provide a more informative exception - this has
already been taken care of in v3.x.
In v3.0, the root exception is:
{code}
org.apache.cassandra.exceptions.InvalidRequestException: Unknown type
autogeneratedtest.map
at
org.apache.cassandra.cql3.CQL3Type$Raw$RawUT.prepare(CQL3Type.java:780)
at
org.apache.cassandra.cql3.statements.CreateTableStatement$RawStatement.prepare(CreateTableStatement.java:225)
at org.apache.cassandra.config.CFMetaData.compile(CFMetaData.java:408)
{code}
whereas in v2.1 and v2.2 the root exception is:
{code}
java.lang.RuntimeException:
org.apache.cassandra.exceptions.InvalidRequestException: Unknown keyspace
autogeneratedtest
at org.apache.cassandra.config.CFMetaData.compile(CFMetaData.java:537)
{code}
was (Author: michaeledge):
{color:red}Note: patch CANNOT be applied to {{v2.1}} or {{v2.2}}. {color}
For these versions the root exception thrown from CFMetaData and CQL3Type does
not provide any useful information regarding data types, unlike the v3.0
underlying exception.
In v3.0, the root exception is:
{code}
org.apache.cassandra.exceptions.InvalidRequestException: Unknown type
autogeneratedtest.map
at
org.apache.cassandra.cql3.CQL3Type$Raw$RawUT.prepare(CQL3Type.java:780)
at
org.apache.cassandra.cql3.statements.CreateTableStatement$RawStatement.prepare(CreateTableStatement.java:225)
at org.apache.cassandra.config.CFMetaData.compile(CFMetaData.java:408)
{code}
whereas in v2.1 and v2.2 the root exception is:
{code}
java.lang.RuntimeException:
org.apache.cassandra.exceptions.InvalidRequestException: Unknown keyspace
autogeneratedtest
at org.apache.cassandra.config.CFMetaData.compile(CFMetaData.java:537)
{code}
> Stress gives "Unknown keyspace" error when a map type is used in user profile
> -
>
> Key: CASSANDRA-10725
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10725
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
>Reporter: Sebastian Estevez
>Assignee: Michael Edge
>Priority: Minor
> Labels: stress, tools
> Fix For: 3.x
>
> Attachments: CASSANDRA-3.0-10725-Cassandra-Stress.patch
>
>
> Steps to reproduce:
> copy the following stress.yaml:
> {code}# Keyspace Name
> keyspace: autogeneratedtest
>
> # The CQL for creating a keyspace (optional if it already exists)
> keyspace_definition: |
> CREATE KEYSPACE autogeneratedtest WITH replication = {'class':
> 'SimpleStrategy', 'replication_factor': 1};
>
> # Table name
> table: smartcity_data
>
> # The CQL for creating a table you wish to stress (optional if it already
> exists)
> table_definition:
> CREATE TABLE smartcity_data (
> device text,
> reporter text,
> time timestamp,
> data_ map,
> metadata_ text,
> solr_query text,
> timeack timestamp,
> timefalse timestamp,
> timeresolved timestamp,
> PRIMARY KEY (device, reporter, time)
> )
> ### Column Distribution Specifications ###
>
> columnspec:
> - name: device
> size: fixed(10)
> population: uniform(1..10)
>
> - name: reporter
> size: fixed(10)
> population: uniform(1..10)
>
> - name: time
> size: fixed(10)
> population: uniform(1..10)
>
> - name: data_
> size: fixed(10)
> population: uniform(1..10)
>
> - name: metadata_
> size: fixed(10)
> population: uniform(1..10)
>
> - name: solr_query
> size: fixed(10)
> population: uniform(1..10)
>
> - name: timeack
> size: fixed(10)
> population: uniform(1..10)
>
> - name: timefalse
> size: fixed(10)
> population: uniform(1..10)
>
> - name: timeresolved
> size: fixed(10)
> population: uniform(1..10)
>
>
> ### Batch Ratio Distribution Specifications ###
>
> insert:
> partitions: fixed(1)# Our partition key is the domain so only
> insert one per batch
>
> select: fixed(1)/1000# We have 1000 posts per domain so 1/1000
> will allow 1 post per batch
>
> batchtype: UNLOGGED # Unlogged batches
>
>
> #
> # A list of queries you wish to run against the schema
> #
> queries:
>likelyquery0:
> cql: Select * from
[jira] [Updated] (CASSANDRA-10725) Stress gives "Unknown keyspace" error when a map type is used in user profile
[
https://issues.apache.org/jira/browse/CASSANDRA-10725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Edge updated CASSANDRA-10725:
-
Fix Version/s: 3.x
> Stress gives "Unknown keyspace" error when a map type is used in user profile
> -
>
> Key: CASSANDRA-10725
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10725
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
>Reporter: Sebastian Estevez
>Assignee: Michael Edge
>Priority: Minor
> Labels: stress, tools
> Fix For: 3.x
>
> Attachments: CASSANDRA-3.0-10725-Cassandra-Stress.patch
>
>
> Steps to reproduce:
> copy the following stress.yaml:
> {code}# Keyspace Name
> keyspace: autogeneratedtest
>
> # The CQL for creating a keyspace (optional if it already exists)
> keyspace_definition: |
> CREATE KEYSPACE autogeneratedtest WITH replication = {'class':
> 'SimpleStrategy', 'replication_factor': 1};
>
> # Table name
> table: smartcity_data
>
> # The CQL for creating a table you wish to stress (optional if it already
> exists)
> table_definition:
> CREATE TABLE smartcity_data (
> device text,
> reporter text,
> time timestamp,
> data_ map,
> metadata_ text,
> solr_query text,
> timeack timestamp,
> timefalse timestamp,
> timeresolved timestamp,
> PRIMARY KEY (device, reporter, time)
> )
> ### Column Distribution Specifications ###
>
> columnspec:
> - name: device
> size: fixed(10)
> population: uniform(1..10)
>
> - name: reporter
> size: fixed(10)
> population: uniform(1..10)
>
> - name: time
> size: fixed(10)
> population: uniform(1..10)
>
> - name: data_
> size: fixed(10)
> population: uniform(1..10)
>
> - name: metadata_
> size: fixed(10)
> population: uniform(1..10)
>
> - name: solr_query
> size: fixed(10)
> population: uniform(1..10)
>
> - name: timeack
> size: fixed(10)
> population: uniform(1..10)
>
> - name: timefalse
> size: fixed(10)
> population: uniform(1..10)
>
> - name: timeresolved
> size: fixed(10)
> population: uniform(1..10)
>
>
> ### Batch Ratio Distribution Specifications ###
>
> insert:
> partitions: fixed(1)# Our partition key is the domain so only
> insert one per batch
>
> select: fixed(1)/1000# We have 1000 posts per domain so 1/1000
> will allow 1 post per batch
>
> batchtype: UNLOGGED # Unlogged batches
>
>
> #
> # A list of queries you wish to run against the schema
> #
> queries:
>likelyquery0:
> cql: Select * from smartcity_data where device = ?
> fields: samerow
>likelyquery1:
> cql: Select * from smartcity_data where device = ? and reporter = ?
> fields: samerow
>likelyquery2:
> cql: Select * from smartcity_data where device = ? and reporter = ? and
> time = ?
> fields: samerow{code}
> and run:
> {code}cassandra-stress user profile=stress.yaml ops\(insert=1\) n=10 -rate
> threads=1
> There was a problem parsing the table cql: Unknown keyspace
> autogeneratedtest{code}
> You'll see the following error:
> {quote}
> There was a problem parsing the table cql: Unknown keyspace autogeneratedtest
> {quote}
> The error should instead state:
> {quote}Maps are not currently supported in cassandra-stress{quote}
> If you replace `data_ map`, with `data_ text` it works fine.
> Related: CASSANDRA-9091
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10725) Stress gives "Unknown keyspace" error when a map type is used in user profile
[
https://issues.apache.org/jira/browse/CASSANDRA-10725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15029428#comment-15029428
]
Michael Edge commented on CASSANDRA-10725:
--
{color:red}Note: patch CANNOT be applied to {{v2.1}} or {{v2.2}}. {color}
For these versions the root exception thrown from CFMetaData and CQL3Type does
not provide any useful information regarding data types, unlike the v3.0
underlying exception.
In v3.0, the root exception is:
{code}
org.apache.cassandra.exceptions.InvalidRequestException: Unknown type
autogeneratedtest.map
at
org.apache.cassandra.cql3.CQL3Type$Raw$RawUT.prepare(CQL3Type.java:780)
at
org.apache.cassandra.cql3.statements.CreateTableStatement$RawStatement.prepare(CreateTableStatement.java:225)
at org.apache.cassandra.config.CFMetaData.compile(CFMetaData.java:408)
{code}
whereas in v2.1 and v2.2 the root exception is:
{code}
java.lang.RuntimeException:
org.apache.cassandra.exceptions.InvalidRequestException: Unknown keyspace
autogeneratedtest
at org.apache.cassandra.config.CFMetaData.compile(CFMetaData.java:537)
{code}
> Stress gives "Unknown keyspace" error when a map type is used in user profile
> -
>
> Key: CASSANDRA-10725
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10725
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
>Reporter: Sebastian Estevez
>Assignee: Michael Edge
>Priority: Minor
> Labels: stress, tools
> Attachments: CASSANDRA-3.0-10725-Cassandra-Stress.patch
>
>
> Steps to reproduce:
> copy the following stress.yaml:
> {code}# Keyspace Name
> keyspace: autogeneratedtest
>
> # The CQL for creating a keyspace (optional if it already exists)
> keyspace_definition: |
> CREATE KEYSPACE autogeneratedtest WITH replication = {'class':
> 'SimpleStrategy', 'replication_factor': 1};
>
> # Table name
> table: smartcity_data
>
> # The CQL for creating a table you wish to stress (optional if it already
> exists)
> table_definition:
> CREATE TABLE smartcity_data (
> device text,
> reporter text,
> time timestamp,
> data_ map,
> metadata_ text,
> solr_query text,
> timeack timestamp,
> timefalse timestamp,
> timeresolved timestamp,
> PRIMARY KEY (device, reporter, time)
> )
> ### Column Distribution Specifications ###
>
> columnspec:
> - name: device
> size: fixed(10)
> population: uniform(1..10)
>
> - name: reporter
> size: fixed(10)
> population: uniform(1..10)
>
> - name: time
> size: fixed(10)
> population: uniform(1..10)
>
> - name: data_
> size: fixed(10)
> population: uniform(1..10)
>
> - name: metadata_
> size: fixed(10)
> population: uniform(1..10)
>
> - name: solr_query
> size: fixed(10)
> population: uniform(1..10)
>
> - name: timeack
> size: fixed(10)
> population: uniform(1..10)
>
> - name: timefalse
> size: fixed(10)
> population: uniform(1..10)
>
> - name: timeresolved
> size: fixed(10)
> population: uniform(1..10)
>
>
> ### Batch Ratio Distribution Specifications ###
>
> insert:
> partitions: fixed(1)# Our partition key is the domain so only
> insert one per batch
>
> select: fixed(1)/1000# We have 1000 posts per domain so 1/1000
> will allow 1 post per batch
>
> batchtype: UNLOGGED # Unlogged batches
>
>
> #
> # A list of queries you wish to run against the schema
> #
> queries:
>likelyquery0:
> cql: Select * from smartcity_data where device = ?
> fields: samerow
>likelyquery1:
> cql: Select * from smartcity_data where device = ? and reporter = ?
> fields: samerow
>likelyquery2:
> cql: Select * from smartcity_data where device = ? and reporter = ? and
> time = ?
> fields: samerow{code}
> and run:
> {code}cassandra-stress user profile=stress.yaml ops\(insert=1\) n=10 -rate
> threads=1
> There was a problem parsing the table cql: Unknown keyspace
> autogeneratedtest{code}
> You'll see the following error:
> {quote}
> There was a problem parsing the table cql: Unknown keyspace autogeneratedtest
> {quote}
> The error should instead state:
> {quote}Maps are not currently supported in cassandra-stress{quote}
> If you replace `data_ map`, with `data_ text` it works fine.
> Related: CASSANDRA-9091
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (CASSANDRA-10725) Stress gives "Unknown keyspace" error when a map type is used in user profile
[
https://issues.apache.org/jira/browse/CASSANDRA-10725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Edge reassigned CASSANDRA-10725:
Assignee: Michael Edge
> Stress gives "Unknown keyspace" error when a map type is used in user profile
> -
>
> Key: CASSANDRA-10725
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10725
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
>Reporter: Sebastian Estevez
>Assignee: Michael Edge
>Priority: Minor
> Labels: stress, tools
> Attachments: CASSANDRA-3.0-10725-Cassandra-Stress.patch
>
>
> Steps to reproduce:
> copy the following stress.yaml:
> {code}# Keyspace Name
> keyspace: autogeneratedtest
>
> # The CQL for creating a keyspace (optional if it already exists)
> keyspace_definition: |
> CREATE KEYSPACE autogeneratedtest WITH replication = {'class':
> 'SimpleStrategy', 'replication_factor': 1};
>
> # Table name
> table: smartcity_data
>
> # The CQL for creating a table you wish to stress (optional if it already
> exists)
> table_definition:
> CREATE TABLE smartcity_data (
> device text,
> reporter text,
> time timestamp,
> data_ map,
> metadata_ text,
> solr_query text,
> timeack timestamp,
> timefalse timestamp,
> timeresolved timestamp,
> PRIMARY KEY (device, reporter, time)
> )
> ### Column Distribution Specifications ###
>
> columnspec:
> - name: device
> size: fixed(10)
> population: uniform(1..10)
>
> - name: reporter
> size: fixed(10)
> population: uniform(1..10)
>
> - name: time
> size: fixed(10)
> population: uniform(1..10)
>
> - name: data_
> size: fixed(10)
> population: uniform(1..10)
>
> - name: metadata_
> size: fixed(10)
> population: uniform(1..10)
>
> - name: solr_query
> size: fixed(10)
> population: uniform(1..10)
>
> - name: timeack
> size: fixed(10)
> population: uniform(1..10)
>
> - name: timefalse
> size: fixed(10)
> population: uniform(1..10)
>
> - name: timeresolved
> size: fixed(10)
> population: uniform(1..10)
>
>
> ### Batch Ratio Distribution Specifications ###
>
> insert:
> partitions: fixed(1)# Our partition key is the domain so only
> insert one per batch
>
> select: fixed(1)/1000# We have 1000 posts per domain so 1/1000
> will allow 1 post per batch
>
> batchtype: UNLOGGED # Unlogged batches
>
>
> #
> # A list of queries you wish to run against the schema
> #
> queries:
>likelyquery0:
> cql: Select * from smartcity_data where device = ?
> fields: samerow
>likelyquery1:
> cql: Select * from smartcity_data where device = ? and reporter = ?
> fields: samerow
>likelyquery2:
> cql: Select * from smartcity_data where device = ? and reporter = ? and
> time = ?
> fields: samerow{code}
> and run:
> {code}cassandra-stress user profile=stress.yaml ops\(insert=1\) n=10 -rate
> threads=1
> There was a problem parsing the table cql: Unknown keyspace
> autogeneratedtest{code}
> You'll see the following error:
> {quote}
> There was a problem parsing the table cql: Unknown keyspace autogeneratedtest
> {quote}
> The error should instead state:
> {quote}Maps are not currently supported in cassandra-stress{quote}
> If you replace `data_ map`, with `data_ text` it works fine.
> Related: CASSANDRA-9091
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10725) Stress gives "Unknown keyspace" error when a map type is used in user profile
[
https://issues.apache.org/jira/browse/CASSANDRA-10725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Edge updated CASSANDRA-10725:
-
Labels: stress tools (was: )
> Stress gives "Unknown keyspace" error when a map type is used in user profile
> -
>
> Key: CASSANDRA-10725
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10725
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
>Reporter: Sebastian Estevez
>Priority: Minor
> Labels: stress, tools
> Attachments: CASSANDRA-3.0-10725-Cassandra-Stress.patch
>
>
> Steps to reproduce:
> copy the following stress.yaml:
> {code}# Keyspace Name
> keyspace: autogeneratedtest
>
> # The CQL for creating a keyspace (optional if it already exists)
> keyspace_definition: |
> CREATE KEYSPACE autogeneratedtest WITH replication = {'class':
> 'SimpleStrategy', 'replication_factor': 1};
>
> # Table name
> table: smartcity_data
>
> # The CQL for creating a table you wish to stress (optional if it already
> exists)
> table_definition:
> CREATE TABLE smartcity_data (
> device text,
> reporter text,
> time timestamp,
> data_ map,
> metadata_ text,
> solr_query text,
> timeack timestamp,
> timefalse timestamp,
> timeresolved timestamp,
> PRIMARY KEY (device, reporter, time)
> )
> ### Column Distribution Specifications ###
>
> columnspec:
> - name: device
> size: fixed(10)
> population: uniform(1..10)
>
> - name: reporter
> size: fixed(10)
> population: uniform(1..10)
>
> - name: time
> size: fixed(10)
> population: uniform(1..10)
>
> - name: data_
> size: fixed(10)
> population: uniform(1..10)
>
> - name: metadata_
> size: fixed(10)
> population: uniform(1..10)
>
> - name: solr_query
> size: fixed(10)
> population: uniform(1..10)
>
> - name: timeack
> size: fixed(10)
> population: uniform(1..10)
>
> - name: timefalse
> size: fixed(10)
> population: uniform(1..10)
>
> - name: timeresolved
> size: fixed(10)
> population: uniform(1..10)
>
>
> ### Batch Ratio Distribution Specifications ###
>
> insert:
> partitions: fixed(1)# Our partition key is the domain so only
> insert one per batch
>
> select: fixed(1)/1000# We have 1000 posts per domain so 1/1000
> will allow 1 post per batch
>
> batchtype: UNLOGGED # Unlogged batches
>
>
> #
> # A list of queries you wish to run against the schema
> #
> queries:
>likelyquery0:
> cql: Select * from smartcity_data where device = ?
> fields: samerow
>likelyquery1:
> cql: Select * from smartcity_data where device = ? and reporter = ?
> fields: samerow
>likelyquery2:
> cql: Select * from smartcity_data where device = ? and reporter = ? and
> time = ?
> fields: samerow{code}
> and run:
> {code}cassandra-stress user profile=stress.yaml ops\(insert=1\) n=10 -rate
> threads=1
> There was a problem parsing the table cql: Unknown keyspace
> autogeneratedtest{code}
> You'll see the following error:
> {quote}
> There was a problem parsing the table cql: Unknown keyspace autogeneratedtest
> {quote}
> The error should instead state:
> {quote}Maps are not currently supported in cassandra-stress{quote}
> If you replace `data_ map`, with `data_ text` it works fine.
> Related: CASSANDRA-9091
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10725) Stress gives "Unknown keyspace" error when a map type is used in user profile
[
https://issues.apache.org/jira/browse/CASSANDRA-10725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Edge updated CASSANDRA-10725:
-
Component/s: Tools
> Stress gives "Unknown keyspace" error when a map type is used in user profile
> -
>
> Key: CASSANDRA-10725
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10725
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
>Reporter: Sebastian Estevez
>Priority: Minor
> Attachments: CASSANDRA-3.0-10725-Cassandra-Stress.patch
>
>
> Steps to reproduce:
> copy the following stress.yaml:
> {code}# Keyspace Name
> keyspace: autogeneratedtest
>
> # The CQL for creating a keyspace (optional if it already exists)
> keyspace_definition: |
> CREATE KEYSPACE autogeneratedtest WITH replication = {'class':
> 'SimpleStrategy', 'replication_factor': 1};
>
> # Table name
> table: smartcity_data
>
> # The CQL for creating a table you wish to stress (optional if it already
> exists)
> table_definition:
> CREATE TABLE smartcity_data (
> device text,
> reporter text,
> time timestamp,
> data_ map,
> metadata_ text,
> solr_query text,
> timeack timestamp,
> timefalse timestamp,
> timeresolved timestamp,
> PRIMARY KEY (device, reporter, time)
> )
> ### Column Distribution Specifications ###
>
> columnspec:
> - name: device
> size: fixed(10)
> population: uniform(1..10)
>
> - name: reporter
> size: fixed(10)
> population: uniform(1..10)
>
> - name: time
> size: fixed(10)
> population: uniform(1..10)
>
> - name: data_
> size: fixed(10)
> population: uniform(1..10)
>
> - name: metadata_
> size: fixed(10)
> population: uniform(1..10)
>
> - name: solr_query
> size: fixed(10)
> population: uniform(1..10)
>
> - name: timeack
> size: fixed(10)
> population: uniform(1..10)
>
> - name: timefalse
> size: fixed(10)
> population: uniform(1..10)
>
> - name: timeresolved
> size: fixed(10)
> population: uniform(1..10)
>
>
> ### Batch Ratio Distribution Specifications ###
>
> insert:
> partitions: fixed(1)# Our partition key is the domain so only
> insert one per batch
>
> select: fixed(1)/1000# We have 1000 posts per domain so 1/1000
> will allow 1 post per batch
>
> batchtype: UNLOGGED # Unlogged batches
>
>
> #
> # A list of queries you wish to run against the schema
> #
> queries:
>likelyquery0:
> cql: Select * from smartcity_data where device = ?
> fields: samerow
>likelyquery1:
> cql: Select * from smartcity_data where device = ? and reporter = ?
> fields: samerow
>likelyquery2:
> cql: Select * from smartcity_data where device = ? and reporter = ? and
> time = ?
> fields: samerow{code}
> and run:
> {code}cassandra-stress user profile=stress.yaml ops\(insert=1\) n=10 -rate
> threads=1
> There was a problem parsing the table cql: Unknown keyspace
> autogeneratedtest{code}
> You'll see the following error:
> {quote}
> There was a problem parsing the table cql: Unknown keyspace autogeneratedtest
> {quote}
> The error should instead state:
> {quote}Maps are not currently supported in cassandra-stress{quote}
> If you replace `data_ map`, with `data_ text` it works fine.
> Related: CASSANDRA-9091
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10725) Stress gives "Unknown keyspace" error when a map type is used in user profile
[
https://issues.apache.org/jira/browse/CASSANDRA-10725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Edge updated CASSANDRA-10725:
-
Attachment: CASSANDRA-3.0-10725-Cassandra-Stress.patch
> Stress gives "Unknown keyspace" error when a map type is used in user profile
> -
>
> Key: CASSANDRA-10725
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10725
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
>Reporter: Sebastian Estevez
>Priority: Minor
> Attachments: CASSANDRA-3.0-10725-Cassandra-Stress.patch
>
>
> Steps to reproduce:
> copy the following stress.yaml:
> {code}# Keyspace Name
> keyspace: autogeneratedtest
>
> # The CQL for creating a keyspace (optional if it already exists)
> keyspace_definition: |
> CREATE KEYSPACE autogeneratedtest WITH replication = {'class':
> 'SimpleStrategy', 'replication_factor': 1};
>
> # Table name
> table: smartcity_data
>
> # The CQL for creating a table you wish to stress (optional if it already
> exists)
> table_definition:
> CREATE TABLE smartcity_data (
> device text,
> reporter text,
> time timestamp,
> data_ map,
> metadata_ text,
> solr_query text,
> timeack timestamp,
> timefalse timestamp,
> timeresolved timestamp,
> PRIMARY KEY (device, reporter, time)
> )
> ### Column Distribution Specifications ###
>
> columnspec:
> - name: device
> size: fixed(10)
> population: uniform(1..10)
>
> - name: reporter
> size: fixed(10)
> population: uniform(1..10)
>
> - name: time
> size: fixed(10)
> population: uniform(1..10)
>
> - name: data_
> size: fixed(10)
> population: uniform(1..10)
>
> - name: metadata_
> size: fixed(10)
> population: uniform(1..10)
>
> - name: solr_query
> size: fixed(10)
> population: uniform(1..10)
>
> - name: timeack
> size: fixed(10)
> population: uniform(1..10)
>
> - name: timefalse
> size: fixed(10)
> population: uniform(1..10)
>
> - name: timeresolved
> size: fixed(10)
> population: uniform(1..10)
>
>
> ### Batch Ratio Distribution Specifications ###
>
> insert:
> partitions: fixed(1)# Our partition key is the domain so only
> insert one per batch
>
> select: fixed(1)/1000# We have 1000 posts per domain so 1/1000
> will allow 1 post per batch
>
> batchtype: UNLOGGED # Unlogged batches
>
>
> #
> # A list of queries you wish to run against the schema
> #
> queries:
>likelyquery0:
> cql: Select * from smartcity_data where device = ?
> fields: samerow
>likelyquery1:
> cql: Select * from smartcity_data where device = ? and reporter = ?
> fields: samerow
>likelyquery2:
> cql: Select * from smartcity_data where device = ? and reporter = ? and
> time = ?
> fields: samerow{code}
> and run:
> {code}cassandra-stress user profile=stress.yaml ops\(insert=1\) n=10 -rate
> threads=1
> There was a problem parsing the table cql: Unknown keyspace
> autogeneratedtest{code}
> You'll see the following error:
> {quote}
> There was a problem parsing the table cql: Unknown keyspace autogeneratedtest
> {quote}
> The error should instead state:
> {quote}Maps are not currently supported in cassandra-stress{quote}
> If you replace `data_ map`, with `data_ text` it works fine.
> Related: CASSANDRA-9091
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10725) Stress gives "Unknown keyspace" error when a map type is used in user profile
[
https://issues.apache.org/jira/browse/CASSANDRA-10725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Edge updated CASSANDRA-10725:
-
Priority: Minor (was: Major)
> Stress gives "Unknown keyspace" error when a map type is used in user profile
> -
>
> Key: CASSANDRA-10725
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10725
> Project: Cassandra
> Issue Type: Bug
>Reporter: Sebastian Estevez
>Priority: Minor
>
> Steps to reproduce:
> copy the following stress.yaml:
> {code}# Keyspace Name
> keyspace: autogeneratedtest
>
> # The CQL for creating a keyspace (optional if it already exists)
> keyspace_definition: |
> CREATE KEYSPACE autogeneratedtest WITH replication = {'class':
> 'SimpleStrategy', 'replication_factor': 1};
>
> # Table name
> table: smartcity_data
>
> # The CQL for creating a table you wish to stress (optional if it already
> exists)
> table_definition:
> CREATE TABLE smartcity_data (
> device text,
> reporter text,
> time timestamp,
> data_ map,
> metadata_ text,
> solr_query text,
> timeack timestamp,
> timefalse timestamp,
> timeresolved timestamp,
> PRIMARY KEY (device, reporter, time)
> )
> ### Column Distribution Specifications ###
>
> columnspec:
> - name: device
> size: fixed(10)
> population: uniform(1..10)
>
> - name: reporter
> size: fixed(10)
> population: uniform(1..10)
>
> - name: time
> size: fixed(10)
> population: uniform(1..10)
>
> - name: data_
> size: fixed(10)
> population: uniform(1..10)
>
> - name: metadata_
> size: fixed(10)
> population: uniform(1..10)
>
> - name: solr_query
> size: fixed(10)
> population: uniform(1..10)
>
> - name: timeack
> size: fixed(10)
> population: uniform(1..10)
>
> - name: timefalse
> size: fixed(10)
> population: uniform(1..10)
>
> - name: timeresolved
> size: fixed(10)
> population: uniform(1..10)
>
>
> ### Batch Ratio Distribution Specifications ###
>
> insert:
> partitions: fixed(1)# Our partition key is the domain so only
> insert one per batch
>
> select: fixed(1)/1000# We have 1000 posts per domain so 1/1000
> will allow 1 post per batch
>
> batchtype: UNLOGGED # Unlogged batches
>
>
> #
> # A list of queries you wish to run against the schema
> #
> queries:
>likelyquery0:
> cql: Select * from smartcity_data where device = ?
> fields: samerow
>likelyquery1:
> cql: Select * from smartcity_data where device = ? and reporter = ?
> fields: samerow
>likelyquery2:
> cql: Select * from smartcity_data where device = ? and reporter = ? and
> time = ?
> fields: samerow{code}
> and run:
> {code}cassandra-stress user profile=stress.yaml ops\(insert=1\) n=10 -rate
> threads=1
> There was a problem parsing the table cql: Unknown keyspace
> autogeneratedtest{code}
> You'll see the following error:
> {quote}
> There was a problem parsing the table cql: Unknown keyspace autogeneratedtest
> {quote}
> The error should instead state:
> {quote}Maps are not currently supported in cassandra-stress{quote}
> If you replace `data_ map`, with `data_ text` it works fine.
> Related: CASSANDRA-9091
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10725) Stress gives "Unknown keyspace" error when a map type is used in user profile
[
https://issues.apache.org/jira/browse/CASSANDRA-10725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15029360#comment-15029360
]
Michael Edge commented on CASSANDRA-10725:
--
[~sebastian.este...@datastax.com], in which version did you discover this?
I tested against trunk and received a NullPointerException. However, the piece
of code causing the NPE is the same line of code that causes your {quote}There
was a problem parsing the table cql: Unknown keyspace autogeneratedtest{quote}
The exception is thrown by {{StressProfile.java}}, and the real underlying
exception is:
{code}
org.apache.cassandra.exceptions.InvalidRequestException: Unknown type
autogeneratedtest.map
{code}
This exception is lost by the line of code in StressProfile.java that throws
the exception. Also, the NPE is thrown by {{e.getCause()}}
{code}
throw new IllegalArgumentException("There was a problem parsing the table cql:
" + e.getCause().getMessage());
{code}
I believe this line of code should be changed to:
{code}
throw new IllegalArgumentException("There was a problem parsing the table cql:
" + e.getMessage());
{code}
After making this change the following message appears:
{quote}There was a problem parsing the table cql: Unknown type
autogeneratedtest.map{quote}
Patch for trunk attached.
> Stress gives "Unknown keyspace" error when a map type is used in user profile
> -
>
> Key: CASSANDRA-10725
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10725
> Project: Cassandra
> Issue Type: Bug
>Reporter: Sebastian Estevez
>
> Steps to reproduce:
> copy the following stress.yaml:
> {code}# Keyspace Name
> keyspace: autogeneratedtest
>
> # The CQL for creating a keyspace (optional if it already exists)
> keyspace_definition: |
> CREATE KEYSPACE autogeneratedtest WITH replication = {'class':
> 'SimpleStrategy', 'replication_factor': 1};
>
> # Table name
> table: smartcity_data
>
> # The CQL for creating a table you wish to stress (optional if it already
> exists)
> table_definition:
> CREATE TABLE smartcity_data (
> device text,
> reporter text,
> time timestamp,
> data_ map,
> metadata_ text,
> solr_query text,
> timeack timestamp,
> timefalse timestamp,
> timeresolved timestamp,
> PRIMARY KEY (device, reporter, time)
> )
> ### Column Distribution Specifications ###
>
> columnspec:
> - name: device
> size: fixed(10)
> population: uniform(1..10)
>
> - name: reporter
> size: fixed(10)
> population: uniform(1..10)
>
> - name: time
> size: fixed(10)
> population: uniform(1..10)
>
> - name: data_
> size: fixed(10)
> population: uniform(1..10)
>
> - name: metadata_
> size: fixed(10)
> population: uniform(1..10)
>
> - name: solr_query
> size: fixed(10)
> population: uniform(1..10)
>
> - name: timeack
> size: fixed(10)
> population: uniform(1..10)
>
> - name: timefalse
> size: fixed(10)
> population: uniform(1..10)
>
> - name: timeresolved
> size: fixed(10)
> population: uniform(1..10)
>
>
> ### Batch Ratio Distribution Specifications ###
>
> insert:
> partitions: fixed(1)# Our partition key is the domain so only
> insert one per batch
>
> select: fixed(1)/1000# We have 1000 posts per domain so 1/1000
> will allow 1 post per batch
>
> batchtype: UNLOGGED # Unlogged batches
>
>
> #
> # A list of queries you wish to run against the schema
> #
> queries:
>likelyquery0:
> cql: Select * from smartcity_data where device = ?
> fields: samerow
>likelyquery1:
> cql: Select * from smartcity_data where device = ? and reporter = ?
> fields: samerow
>likelyquery2:
> cql: Select * from smartcity_data where device = ? and reporter = ? and
> time = ?
> fields: samerow{code}
> and run:
> {code}cassandra-stress user profile=stress.yaml ops\(insert=1\) n=10 -rate
> threads=1
> There was a problem parsing the table cql: Unknown keyspace
> autogeneratedtest{code}
> You'll see the following error:
> {quote}
> There was a problem parsing the table cql: Unknown keyspace autogeneratedtest
> {quote}
> The error should instead state:
> {quote}Maps are not currently supported in cassandra-stress{quote}
> If you replace `data_ map`, with `data_ text` it works fine.
> Related: CASSANDRA-9091
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-10760) Counters are erroneously allowed as map key type
[
https://issues.apache.org/jira/browse/CASSANDRA-10760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15026524#comment-15026524
]
Michael Edge edited comment on CASSANDRA-10760 at 11/25/15 10:44 AM:
-
[~iamaleksey], if this is what you're expecting I'll create patches for v2.1
and v2.2.
{noformat}
cqlsh> create keyspace test with replication = {'class': 'SimpleStrategy',
'replication_factor': 1};
cqlsh> create table test.test (id int primary key, amap map);
InvalidRequest: code=2200 [Invalid query] message="Counters are not allowed as
keys inside collections: map"
cqlsh> create table test.test (id int primary key, amap map);
InvalidRequest: code=2200 [Invalid query] message="Counters are not allowed as
values inside collections: map"
cqlsh:test> create table test.test (id int primary key, alist list);
InvalidRequest: code=2200 [Invalid query] message="Counters are not allowed as
values inside collections: list"
{noformat}
Note the error message for LIST is the same as for MAP (both refer to 'values
inside collections'). If this is confusing I'll just remove the 'as values'.
One thing I'm not 100% sure of is whether we allow counters as map keys for
supercolumns. Seems we do allow counters as map values for supercolumns. If we
do not allow them as map keys then the {{isInternal}} check in
{{org/apache/cassandra/cql3/CQL3Type.java}} can be removed (see patch).
{code}
+if (keys.isCounter() && !isInternal)
+throw new InvalidRequestException("Counters are not
allowed as keys inside collections: " + this);
{code}
was (Author: michaeledge):
[~iamaleksey], if this is what you're expecting I'll create patches for v2.1
and v2.2.
{noformat}
cqlsh> create keyspace test with replication = {'class': 'SimpleStrategy',
'replication_factor': 1};
cqlsh> create table test.test (id int primary key, amap map);
InvalidRequest: code=2200 [Invalid query] message="Counters are not allowed as
keys inside collections: map"
cqlsh> create table test.test (id int primary key, amap map);
InvalidRequest: code=2200 [Invalid query] message="Counters are not allowed as
values inside collections: map"
{noformat}
One thing I'm not 100% sure of is whether we allow counters as map keys for
supercolumns. Seems we do allow counters as map values for supercolumns. If we
do not allow them as map keys then the {{isInternal}} check in
{{org/apache/cassandra/cql3/CQL3Type.java}} can be removed (see patch).
{code}
+if (keys.isCounter() && !isInternal)
+throw new InvalidRequestException("Counters are not
allowed as keys inside collections: " + this);
{code}
> Counters are erroneously allowed as map key type
>
>
> Key: CASSANDRA-10760
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10760
> Project: Cassandra
> Issue Type: Bug
> Components: CQL
>Reporter: Aleksey Yeschenko
>Assignee: Michael Edge
>Priority: Minor
> Labels: cql, cqlsh
> Fix For: 2.1.x, 2.2.x, 3.0.x
>
> Attachments: CASSANDRA-3.0-10760-Counters-in-Maps.patch
>
>
> We do validate collection value types, but not collection key types, which
> allows counters to be used as map keys:
> {noformat}
> cqlsh> create keyspace test with replication = {'class': 'SimpleStrategy',
> 'replication_factor': 1};
> cqlsh> use test;
> cqlsh:test> create table test.test (id int primary key, amap map text>);
> cqlsh:test> insert into test.test (id, amap) values (0, {1: '2'});
> cqlsh:test> select * from test.test;
> id | amap
> +--
> 0 | {1: '2'}
> (1 rows)
> {noformat}
> This should obviously not be allowed and must be rejected.
> /cc [~slebresne]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10760) Counters are erroneously allowed as map key type
[
https://issues.apache.org/jira/browse/CASSANDRA-10760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Edge updated CASSANDRA-10760:
-
Labels: cql cqlsh (was: )
> Counters are erroneously allowed as map key type
>
>
> Key: CASSANDRA-10760
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10760
> Project: Cassandra
> Issue Type: Bug
> Components: CQL
>Reporter: Aleksey Yeschenko
>Assignee: Michael Edge
>Priority: Minor
> Labels: cql, cqlsh
> Fix For: 2.1.x, 2.2.x, 3.0.x
>
> Attachments: CASSANDRA-3.0-10760-Counters-in-Maps.patch
>
>
> We do validate collection value types, but not collection key types, which
> allows counters to be used as map keys:
> {noformat}
> cqlsh> create keyspace test with replication = {'class': 'SimpleStrategy',
> 'replication_factor': 1};
> cqlsh> use test;
> cqlsh:test> create table test.test (id int primary key, amap map text>);
> cqlsh:test> insert into test.test (id, amap) values (0, {1: '2'});
> cqlsh:test> select * from test.test;
> id | amap
> +--
> 0 | {1: '2'}
> (1 rows)
> {noformat}
> This should obviously not be allowed and must be rejected.
> /cc [~slebresne]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10760) Counters are erroneously allowed as map key type
[
https://issues.apache.org/jira/browse/CASSANDRA-10760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Edge updated CASSANDRA-10760:
-
Attachment: CASSANDRA-3.0-10760-Counters-in-Maps.patch
Patch for v3.0
> Counters are erroneously allowed as map key type
>
>
> Key: CASSANDRA-10760
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10760
> Project: Cassandra
> Issue Type: Bug
> Components: CQL
>Reporter: Aleksey Yeschenko
>Priority: Minor
> Fix For: 2.1.x, 2.2.x, 3.0.x
>
> Attachments: CASSANDRA-3.0-10760-Counters-in-Maps.patch
>
>
> We do validate collection value types, but not collection key types, which
> allows counters to be used as map keys:
> {noformat}
> cqlsh> create keyspace test with replication = {'class': 'SimpleStrategy',
> 'replication_factor': 1};
> cqlsh> use test;
> cqlsh:test> create table test.test (id int primary key, amap map text>);
> cqlsh:test> insert into test.test (id, amap) values (0, {1: '2'});
> cqlsh:test> select * from test.test;
> id | amap
> +--
> 0 | {1: '2'}
> (1 rows)
> {noformat}
> This should obviously not be allowed and must be rejected.
> /cc [~slebresne]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-10760) Counters are erroneously allowed as map key type
[
https://issues.apache.org/jira/browse/CASSANDRA-10760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15026524#comment-15026524
]
Michael Edge edited comment on CASSANDRA-10760 at 11/25/15 10:03 AM:
-
[~iamaleksey], if this is what you're expecting I'll create patches for v2.1
and v2.2.
{noformat}
cqlsh> create keyspace test with replication = {'class': 'SimpleStrategy',
'replication_factor': 1};
cqlsh> create table test.test (id int primary key, amap map);
InvalidRequest: code=2200 [Invalid query] message="Counters are not allowed as
keys inside collections: map"
cqlsh> create table test.test (id int primary key, amap map);
InvalidRequest: code=2200 [Invalid query] message="Counters are not allowed as
values inside collections: map"
{noformat}
One thing I'm not 100% sure of is whether we allow counters as map keys for
supercolumns. Seems we do allow counters as map values for supercolumns. If we
do not allow them as map keys then the {{isInternal}} check in
{{org/apache/cassandra/cql3/CQL3Type.java}} can be removed (see patch).
{code}
+if (keys.isCounter() && !isInternal)
+throw new InvalidRequestException("Counters are not
allowed as keys inside collections: " + this);
{code}
was (Author: michaeledge):
[~iamaleksey], if this is what you're expecting I'll create patches for v2.1
and v2.2.
{noformat}
cqlsh> create keyspace test with replication = {'class': 'SimpleStrategy',
'replication_factor': 1};
cqlsh> create table test.test (id int primary key, amap map);
InvalidRequest: code=2200 [Invalid query] message="Counters are not allowed as
keys inside collections: map"
cqlsh> create table test.test (id int primary key, amap map);
InvalidRequest: code=2200 [Invalid query] message="Counters are not allowed as
values inside collections: map"
{noformat}
One thing I'm not 100% sure of is whether we allow counters as map keys for
supercolumns. Seems we do allow counters as map values for supercolumns. If we
do not allow them as map keys then the {{isInternal}} check in the patch can be
removed.
{code}
+if (keys.isCounter() && !isInternal)
+throw new InvalidRequestException("Counters are not
allowed as keys inside collections: " + this);
{code}
> Counters are erroneously allowed as map key type
>
>
> Key: CASSANDRA-10760
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10760
> Project: Cassandra
> Issue Type: Bug
> Components: CQL
>Reporter: Aleksey Yeschenko
>Priority: Minor
> Fix For: 2.1.x, 2.2.x, 3.0.x
>
>
> We do validate collection value types, but not collection key types, which
> allows counters to be used as map keys:
> {noformat}
> cqlsh> create keyspace test with replication = {'class': 'SimpleStrategy',
> 'replication_factor': 1};
> cqlsh> use test;
> cqlsh:test> create table test.test (id int primary key, amap map text>);
> cqlsh:test> insert into test.test (id, amap) values (0, {1: '2'});
> cqlsh:test> select * from test.test;
> id | amap
> +--
> 0 | {1: '2'}
> (1 rows)
> {noformat}
> This should obviously not be allowed and must be rejected.
> /cc [~slebresne]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-10760) Counters are erroneously allowed as map key type
[
https://issues.apache.org/jira/browse/CASSANDRA-10760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15026524#comment-15026524
]
Michael Edge edited comment on CASSANDRA-10760 at 11/25/15 10:02 AM:
-
[~iamaleksey], if this is what you're expecting I'll create patches for v2.1
and v2.2.
{noformat}
cqlsh> create keyspace test with replication = {'class': 'SimpleStrategy',
'replication_factor': 1};
cqlsh> create table test.test (id int primary key, amap map);
InvalidRequest: code=2200 [Invalid query] message="Counters are not allowed as
keys inside collections: map"
cqlsh> create table test.test (id int primary key, amap map);
InvalidRequest: code=2200 [Invalid query] message="Counters are not allowed as
values inside collections: map"
{noformat}
One thing I'm not 100% sure of is whether we allow counters as map keys for
supercolumns. Seems we do allow counters as map values for supercolumns. If we
do not allow them as map keys then the {{isInternal}} check in the patch can be
removed.
{code}
+if (keys.isCounter() && !isInternal)
+throw new InvalidRequestException("Counters are not
allowed as keys inside collections: " + this);
{code}
was (Author: michaeledge):
[~iamaleksey], if this is what you're expecting I'll create patches for v2.1
and v2.2.
{noformat}
cqlsh> create keyspace test with replication = {'class': 'SimpleStrategy',
'replication_factor': 1};
cqlsh> create table test.test (id int primary key, amap map);
InvalidRequest: code=2200 [Invalid query] message="Counters are not allowed as
keys inside collections: map"
cqlsh> create table test.test (id int primary key, amap map);
InvalidRequest: code=2200 [Invalid query] message="Counters are not allowed as
values inside collections: map"
{noformat}
> Counters are erroneously allowed as map key type
>
>
> Key: CASSANDRA-10760
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10760
> Project: Cassandra
> Issue Type: Bug
> Components: CQL
>Reporter: Aleksey Yeschenko
>Priority: Minor
> Fix For: 2.1.x, 2.2.x, 3.0.x
>
>
> We do validate collection value types, but not collection key types, which
> allows counters to be used as map keys:
> {noformat}
> cqlsh> create keyspace test with replication = {'class': 'SimpleStrategy',
> 'replication_factor': 1};
> cqlsh> use test;
> cqlsh:test> create table test.test (id int primary key, amap map text>);
> cqlsh:test> insert into test.test (id, amap) values (0, {1: '2'});
> cqlsh:test> select * from test.test;
> id | amap
> +--
> 0 | {1: '2'}
> (1 rows)
> {noformat}
> This should obviously not be allowed and must be rejected.
> /cc [~slebresne]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10760) Counters are erroneously allowed as map key type
[
https://issues.apache.org/jira/browse/CASSANDRA-10760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15026524#comment-15026524
]
Michael Edge commented on CASSANDRA-10760:
--
[~iamaleksey], if this is what you're expecting I'll create patches for v2.1
and v2.2.
{noformat}
cqlsh> create keyspace test with replication = {'class': 'SimpleStrategy',
'replication_factor': 1};
cqlsh> create table test.test (id int primary key, amap map);
InvalidRequest: code=2200 [Invalid query] message="Counters are not allowed as
keys inside collections: map"
cqlsh> create table test.test (id int primary key, amap map);
InvalidRequest: code=2200 [Invalid query] message="Counters are not allowed as
values inside collections: map"
{noformat}
> Counters are erroneously allowed as map key type
>
>
> Key: CASSANDRA-10760
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10760
> Project: Cassandra
> Issue Type: Bug
> Components: CQL
>Reporter: Aleksey Yeschenko
>Priority: Minor
> Fix For: 2.1.x, 2.2.x, 3.0.x
>
>
> We do validate collection value types, but not collection key types, which
> allows counters to be used as map keys:
> {noformat}
> cqlsh> create keyspace test with replication = {'class': 'SimpleStrategy',
> 'replication_factor': 1};
> cqlsh> use test;
> cqlsh:test> create table test.test (id int primary key, amap map text>);
> cqlsh:test> insert into test.test (id, amap) values (0, {1: '2'});
> cqlsh:test> select * from test.test;
> id | amap
> +--
> 0 | {1: '2'}
> (1 rows)
> {noformat}
> This should obviously not be allowed and must be rejected.
> /cc [~slebresne]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8369) Better error handling in CQLSH for invalid password
[ https://issues.apache.org/jira/browse/CASSANDRA-8369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Edge updated CASSANDRA-8369: Component/s: Tools > Better error handling in CQLSH for invalid password > --- > > Key: CASSANDRA-8369 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8369 > Project: Cassandra > Issue Type: Improvement > Components: Tools >Reporter: Johnny Miller >Priority: Minor > Labels: cqlsh, tools > > On C* 2.0.11/Cqlsh 4.1.1 when logging with an invalid password you get back a > stacktrace rather than a more user friendly error. It might be better if this > was more user friendly. > For example - this is what you get back now: > root@cass1:~# cqlsh -u cassandra -p johnny > Traceback (most recent call last): > File "/usr/bin/cqlsh", line 2113, in > main(*read_options(sys.argv[1:], os.environ)) > File "/usr/bin/cqlsh", line 2093, in main > single_statement=options.execute) > File "/usr/bin/cqlsh", line 505, in __init__ > password=password, cql_version=cqlver, transport=transport) > File > "/usr/share/dse/cassandra/lib/cql-internal-only-1.4.1.zip/cql-1.4.1/cql/connection.py", > line 143, in connect > File > "/usr/share/dse/cassandra/lib/cql-internal-only-1.4.1.zip/cql-1.4.1/cql/connection.py", > line 59, in __init__ > File > "/usr/share/dse/cassandra/lib/cql-internal-only-1.4.1.zip/cql-1.4.1/cql/thrifteries.py", > line 157, in establish_connection > File > "/usr/share/dse/cassandra/lib/cql-internal-only-1.4.1.zip/cql-1.4.1/cql/cassandra/Cassandra.py", > line 465, in login > File > "/usr/share/dse/cassandra/lib/cql-internal-only-1.4.1.zip/cql-1.4.1/cql/cassandra/Cassandra.py", > line 486, in recv_login > cql.cassandra.ttypes.AuthenticationException: > AuthenticationException(why='Username and/or password are incorrect') -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8369) Better error handling in CQLSH for invalid password
[ https://issues.apache.org/jira/browse/CASSANDRA-8369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Edge updated CASSANDRA-8369: Labels: cqlsh tools (was: ) > Better error handling in CQLSH for invalid password > --- > > Key: CASSANDRA-8369 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8369 > Project: Cassandra > Issue Type: Improvement > Components: Tools >Reporter: Johnny Miller >Priority: Minor > Labels: cqlsh, tools > > On C* 2.0.11/Cqlsh 4.1.1 when logging with an invalid password you get back a > stacktrace rather than a more user friendly error. It might be better if this > was more user friendly. > For example - this is what you get back now: > root@cass1:~# cqlsh -u cassandra -p johnny > Traceback (most recent call last): > File "/usr/bin/cqlsh", line 2113, in > main(*read_options(sys.argv[1:], os.environ)) > File "/usr/bin/cqlsh", line 2093, in main > single_statement=options.execute) > File "/usr/bin/cqlsh", line 505, in __init__ > password=password, cql_version=cqlver, transport=transport) > File > "/usr/share/dse/cassandra/lib/cql-internal-only-1.4.1.zip/cql-1.4.1/cql/connection.py", > line 143, in connect > File > "/usr/share/dse/cassandra/lib/cql-internal-only-1.4.1.zip/cql-1.4.1/cql/connection.py", > line 59, in __init__ > File > "/usr/share/dse/cassandra/lib/cql-internal-only-1.4.1.zip/cql-1.4.1/cql/thrifteries.py", > line 157, in establish_connection > File > "/usr/share/dse/cassandra/lib/cql-internal-only-1.4.1.zip/cql-1.4.1/cql/cassandra/Cassandra.py", > line 465, in login > File > "/usr/share/dse/cassandra/lib/cql-internal-only-1.4.1.zip/cql-1.4.1/cql/cassandra/Cassandra.py", > line 486, in recv_login > cql.cassandra.ttypes.AuthenticationException: > AuthenticationException(why='Username and/or password are incorrect') -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8369) Better error handling in CQLSH for invalid password
[
https://issues.apache.org/jira/browse/CASSANDRA-8369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15026061#comment-15026061
]
Michael Edge commented on CASSANDRA-8369:
-
Tested this on v2.1, 2.2 and 3.0 and we do receive a more user-friendly error.
h3. Version 2.1
{code}
[cass21@localhost ~]$ cqlsh -u cassandra -p johnny
Connection error: ('Unable to connect to any servers', {'127.0.0.1':
AuthenticationFailed(u'Failed to authenticate to 127.0.0.1: code=0100 [Bad
credentials] message="Username and/or password are incorrect"',)})
{code}
>From within CQLSH
{code}
cassandra@cqlsh> login cassandra
Password:
('Unable to connect to any servers', {'127.0.0.1':
AuthenticationFailed(u'Failed to authenticate to 127.0.0.1: code=0100 [Bad
credentials] message="Username and/or password are incorrect"',)})
{code}
h3. Version 2.2
{code}
[cass22@localhost ~]$ cqlsh -u cassandra -p johnny
Connection error: ('Unable to connect to any servers', {'127.0.0.1':
AuthenticationFailed(u'Failed to authenticate to 127.0.0.1: code=0100 [Bad
credentials] message="Username and/or password are incorrect"',)})
{code}
>From within CQLSH
{code}
cassandra@cqlsh> login cassandra
Password:
('Unable to connect to any servers', {'127.0.0.1':
AuthenticationFailed(u'Failed to authenticate to 127.0.0.1: code=0100 [Bad
credentials] message="Username and/or password are incorrect"',)})
{code}
h3. Version 3.0
{code}
[cass30@localhost ~]$ cqlsh -u cassandra -p johnny
Connection error: ('Unable to connect to any servers', {'127.0.0.1':
AuthenticationFailed(u'Failed to authenticate to 127.0.0.1: code=0100 [Bad
credentials] message="Username and/or password are incorrect"',)})
{code}
>From within CQLSH
{code}
cassandra@cqlsh> login cassandra
Password:
('Unable to connect to any servers', {'127.0.0.1':
AuthenticationFailed(u'Failed to authenticate to 127.0.0.1: code=0100 [Bad
credentials] message="Username and/or password are incorrect"',)})
{code}
> Better error handling in CQLSH for invalid password
> ---
>
> Key: CASSANDRA-8369
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8369
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Johnny Miller
>Priority: Minor
>
> On C* 2.0.11/Cqlsh 4.1.1 when logging with an invalid password you get back a
> stacktrace rather than a more user friendly error. It might be better if this
> was more user friendly.
> For example - this is what you get back now:
> root@cass1:~# cqlsh -u cassandra -p johnny
> Traceback (most recent call last):
> File "/usr/bin/cqlsh", line 2113, in
> main(*read_options(sys.argv[1:], os.environ))
> File "/usr/bin/cqlsh", line 2093, in main
> single_statement=options.execute)
> File "/usr/bin/cqlsh", line 505, in __init__
> password=password, cql_version=cqlver, transport=transport)
> File
> "/usr/share/dse/cassandra/lib/cql-internal-only-1.4.1.zip/cql-1.4.1/cql/connection.py",
> line 143, in connect
> File
> "/usr/share/dse/cassandra/lib/cql-internal-only-1.4.1.zip/cql-1.4.1/cql/connection.py",
> line 59, in __init__
> File
> "/usr/share/dse/cassandra/lib/cql-internal-only-1.4.1.zip/cql-1.4.1/cql/thrifteries.py",
> line 157, in establish_connection
> File
> "/usr/share/dse/cassandra/lib/cql-internal-only-1.4.1.zip/cql-1.4.1/cql/cassandra/Cassandra.py",
> line 465, in login
> File
> "/usr/share/dse/cassandra/lib/cql-internal-only-1.4.1.zip/cql-1.4.1/cql/cassandra/Cassandra.py",
> line 486, in recv_login
> cql.cassandra.ttypes.AuthenticationException:
> AuthenticationException(why='Username and/or password are incorrect')
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-8935) cqlsh: Make the column order in COPY FROM more apparent
[
https://issues.apache.org/jira/browse/CASSANDRA-8935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15025992#comment-15025992
]
Michael Edge edited comment on CASSANDRA-8935 at 11/25/15 2:05 AM:
---
Patches attached for v2.1, 2.2 and 3.0.
Output will be as follows:
{code}
cqlsh:cats> copy cats from 'cats.csv' ;
Starting copy of cats.cats with columns ['block_id', 'breed', 'color',
'short_hair', 'age'].
7 rows imported in 0.338 seconds.
{code}
was (Author: michaeledge):
Patches attached for v2.1, 2.2 and 3.0
> cqlsh: Make the column order in COPY FROM more apparent
> ---
>
> Key: CASSANDRA-8935
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8935
> Project: Cassandra
> Issue Type: Improvement
> Components: Tools
>Reporter: Tyler Hobbs
>Assignee: Michael Edge
>Priority: Trivial
> Labels: cqlsh, tools
> Fix For: 2.1.x
>
> Attachments: CASSANDRA-2.1-8935-CQLSH-COPY-FROM.patch,
> CASSANDRA-2.2-8935-CQLSH-COPY-FROM.patch,
> CASSANDRA-3.0-8935-CQLSH-COPY-FROM.patch
>
>
> When running {{COPY FROM}}, we should print the order of columns that we're
> expecting to make it more obvious when the data is not properly aligned.
> Otherwise, the user will simply see a type or syntax error and have to try to
> decipher it.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8935) cqlsh: Make the column order in COPY FROM more apparent
[
https://issues.apache.org/jira/browse/CASSANDRA-8935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Edge updated CASSANDRA-8935:
Attachment: CASSANDRA-3.0-8935-CQLSH-COPY-FROM.patch
CASSANDRA-2.2-8935-CQLSH-COPY-FROM.patch
CASSANDRA-2.1-8935-CQLSH-COPY-FROM.patch
> cqlsh: Make the column order in COPY FROM more apparent
> ---
>
> Key: CASSANDRA-8935
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8935
> Project: Cassandra
> Issue Type: Improvement
> Components: Tools
>Reporter: Tyler Hobbs
>Assignee: Michael Edge
>Priority: Trivial
> Labels: cqlsh
> Fix For: 2.1.x
>
> Attachments: CASSANDRA-2.1-8935-CQLSH-COPY-FROM.patch,
> CASSANDRA-2.2-8935-CQLSH-COPY-FROM.patch,
> CASSANDRA-3.0-8935-CQLSH-COPY-FROM.patch
>
>
> When running {{COPY FROM}}, we should print the order of columns that we're
> expecting to make it more obvious when the data is not properly aligned.
> Otherwise, the user will simply see a type or syntax error and have to try to
> decipher it.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (CASSANDRA-8935) cqlsh: Make the column order in COPY FROM more apparent
[
https://issues.apache.org/jira/browse/CASSANDRA-8935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Edge reassigned CASSANDRA-8935:
---
Assignee: Michael Edge
> cqlsh: Make the column order in COPY FROM more apparent
> ---
>
> Key: CASSANDRA-8935
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8935
> Project: Cassandra
> Issue Type: Improvement
> Components: Tools
>Reporter: Tyler Hobbs
>Assignee: Michael Edge
>Priority: Trivial
> Labels: cqlsh
> Fix For: 2.1.x
>
>
> When running {{COPY FROM}}, we should print the order of columns that we're
> expecting to make it more obvious when the data is not properly aligned.
> Otherwise, the user will simply see a type or syntax error and have to try to
> decipher it.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-8935) cqlsh: Make the column order in COPY FROM more apparent
[
https://issues.apache.org/jira/browse/CASSANDRA-8935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15021503#comment-15021503
]
Michael Edge edited comment on CASSANDRA-8935 at 11/23/15 10:28 AM:
Tyler, just want to confirm that this is what you are thinking of:
{code}
cqlsh:cats> copy cats (block_id, breed, color, short_hair, age) from 'cats.csv';
starting copy cats.cats ['block_id', 'breed', 'color', 'short_hair', 'age'].
7 rows imported in 0.324 seconds.
{code}
or this when no columns are specified:
{code}
cqlsh:cats> copy cats from 'cats.csv';
starting copy cats.cats ['block_id', 'breed', 'color', 'short_hair', 'age'].
7 rows imported in 0.276 seconds.
{code}
If so, I'll upload the patch.
was (Author: michaeledge):
Tyler, just want to confirm that this is what you are thinking of:
{code}
cqlsh:cats> copy cats (block_id, breed, color, short_hair, age) from 'cats.csv';
starting copy cats.cats ['block_id', 'breed', 'color', 'short_hair', 'age'].
7 rows imported in 0.324 seconds.
{code}
or this is no columns are specified:
{code}
cqlsh:cats> copy cats from 'cats.csv';
starting copy cats.cats ['block_id', 'breed', 'color', 'short_hair', 'age'].
7 rows imported in 0.276 seconds.
{code}
If so, I'll upload the patch.
> cqlsh: Make the column order in COPY FROM more apparent
> ---
>
> Key: CASSANDRA-8935
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8935
> Project: Cassandra
> Issue Type: Improvement
> Components: Tools
>Reporter: Tyler Hobbs
>Priority: Trivial
> Labels: cqlsh
> Fix For: 2.1.x
>
>
> When running {{COPY FROM}}, we should print the order of columns that we're
> expecting to make it more obvious when the data is not properly aligned.
> Otherwise, the user will simply see a type or syntax error and have to try to
> decipher it.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8935) cqlsh: Make the column order in COPY FROM more apparent
[
https://issues.apache.org/jira/browse/CASSANDRA-8935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15021503#comment-15021503
]
Michael Edge commented on CASSANDRA-8935:
-
Tyler, just want to confirm that this is what you are thinking of:
{code}
cqlsh:cats> copy cats (block_id, breed, color, short_hair, age) from 'cats.csv';
starting copy cats.cats ['block_id', 'breed', 'color', 'short_hair', 'age'].
7 rows imported in 0.324 seconds.
{code}
or this is no columns are specified:
{code}
cqlsh:cats> copy cats from 'cats.csv';
starting copy cats.cats ['block_id', 'breed', 'color', 'short_hair', 'age'].
7 rows imported in 0.276 seconds.
{code}
If so, I'll upload the patch.
> cqlsh: Make the column order in COPY FROM more apparent
> ---
>
> Key: CASSANDRA-8935
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8935
> Project: Cassandra
> Issue Type: Improvement
> Components: Tools
>Reporter: Tyler Hobbs
>Priority: Trivial
> Labels: cqlsh
> Fix For: 2.1.x
>
>
> When running {{COPY FROM}}, we should print the order of columns that we're
> expecting to make it more obvious when the data is not properly aligned.
> Otherwise, the user will simply see a type or syntax error and have to try to
> decipher it.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10733) Inconsistencies in CQLSH auto-complete
[
https://issues.apache.org/jira/browse/CASSANDRA-10733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Edge updated CASSANDRA-10733:
-
Attachment: CASSANDRA-2.2-10733-CQLSH-Auto.patch
Patch for v2.2.
No patch required for v2.1 as this only impacts AGGREGATES, which were added in
v2.2
> Inconsistencies in CQLSH auto-complete
> --
>
> Key: CASSANDRA-10733
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10733
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL, Tools
>Reporter: Michael Edge
>Assignee: Michael Edge
>Priority: Trivial
> Labels: cqlsh, lhf
> Fix For: 2.1.x, 2.2.x, 3.x
>
> Attachments: CASSANDRA-2.2-10733-CQLSH-Auto.patch,
> CASSANDRA-3.0-10733-CQLSH-Auto.patch
>
>
> Auto-complete in cqlsh does not work correctly on some commands. We see some
> inconsistent behaviour when completing part of the statement and hitting the
> tab key.
> {color:green}Works correctly{color}
> Auto-complete on {{'desc table '}}, {{'desc function '}} and {{'desc type '}}
> works correctly. We see a list of all tables (or functions, types) in the
> current keyspace plus a list of all available keyspaces followed by a full
> stop (e.g. system.)
> {code}
> cqlsh:fxaggr> desc TABLE
> minutedata system_distributed.
> ;rawtickdatabylp system_traces.
> rawtickdatabysymbol tickdata
> daydata system.
> fxaggr. system_auth.
> {code}
> {color:red}Fix required{color}
> {{'desc aggregate '}} displays the aggregates in the current keyspace (in
> this case, only 1, called 'average') but does not display a list of available
> keyspaces. It only displays the current keyspace, with no following full stop.
> {code}
> cqlsh:fxaggr> desc aggregate
> ; average fxaggr
> {code}
> {color:green}Works correctly{color}
> Auto-complete on {{'desc table . '}} and {{'desc type
> .'}} works correctly. We see a list of all tables (or types) in the
> current keyspace
> {code}
> cqlsh:fxaggr> desc table fxaggr.
> daydata rawtickdatabylp tickdata
> minutedata rawtickdatabysymbol
> {code}
> {color:red}Fix required{color}
> Auto-complete on {{'desc function . '}} and {{'desc aggregate
> .'}} works inconsistently. In a keyspace with 2 functions, both
> beginning with the letters 'avg', if I type {{'desc function '}}
> and hit tab, auto-complete will result in this: {{'desc function fxaggr.avg
> '}} and will not display the matching functions. If I type {{'desc function
> .'}} (note the trailing full stop) and hit tab, auto-complete will
> work correctly:
> {code}
> cqlsh:fxaggr> desc function fxaggr.avg
> avgfinal avgstate
> {code}
> If I type {{'desc aggregate '}} and hit tab, auto-complete returns
> {{'desc aggregate '}} (it adds a space) and does not show me the
> list of available aggregates. If I type {{'desc aggregate .'}}
> (note the trailing full stop) and hit tab, auto-complete will work correctly.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-10733) Inconsistencies in CQLSH auto-complete
[
https://issues.apache.org/jira/browse/CASSANDRA-10733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15015574#comment-15015574
]
Michael Edge edited comment on CASSANDRA-10733 at 11/20/15 11:02 AM:
-
Patch for v3.0 to fix first of the two issues mentioned in this JIRA. I'll add
patches for v2.1 and v2.2 soon.
was (Author: michaeledge):
Patch to fix first of the two issues mentioned in this JIRA.
> Inconsistencies in CQLSH auto-complete
> --
>
> Key: CASSANDRA-10733
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10733
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL, Tools
>Reporter: Michael Edge
>Assignee: Michael Edge
>Priority: Trivial
> Labels: cqlsh, lhf
> Fix For: 2.1.x, 2.2.x, 3.x
>
> Attachments: CASSANDRA-3.0-10733-CQLSH-Auto.patch
>
>
> Auto-complete in cqlsh does not work correctly on some commands. We see some
> inconsistent behaviour when completing part of the statement and hitting the
> tab key.
> {color:green}Works correctly{color}
> Auto-complete on {{'desc table '}}, {{'desc function '}} and {{'desc type '}}
> works correctly. We see a list of all tables (or functions, types) in the
> current keyspace plus a list of all available keyspaces followed by a full
> stop (e.g. system.)
> {code}
> cqlsh:fxaggr> desc TABLE
> minutedata system_distributed.
> ;rawtickdatabylp system_traces.
> rawtickdatabysymbol tickdata
> daydata system.
> fxaggr. system_auth.
> {code}
> {color:red}Fix required{color}
> {{'desc aggregate '}} displays the aggregates in the current keyspace (in
> this case, only 1, called 'average') but does not display a list of available
> keyspaces. It only displays the current keyspace, with no following full stop.
> {code}
> cqlsh:fxaggr> desc aggregate
> ; average fxaggr
> {code}
> {color:green}Works correctly{color}
> Auto-complete on {{'desc table . '}} and {{'desc type
> .'}} works correctly. We see a list of all tables (or types) in the
> current keyspace
> {code}
> cqlsh:fxaggr> desc table fxaggr.
> daydata rawtickdatabylp tickdata
> minutedata rawtickdatabysymbol
> {code}
> {color:red}Fix required{color}
> Auto-complete on {{'desc function . '}} and {{'desc aggregate
> .'}} works inconsistently. In a keyspace with 2 functions, both
> beginning with the letters 'avg', if I type {{'desc function '}}
> and hit tab, auto-complete will result in this: {{'desc function fxaggr.avg
> '}} and will not display the matching functions. If I type {{'desc function
> .'}} (note the trailing full stop) and hit tab, auto-complete will
> work correctly:
> {code}
> cqlsh:fxaggr> desc function fxaggr.avg
> avgfinal avgstate
> {code}
> If I type {{'desc aggregate '}} and hit tab, auto-complete returns
> {{'desc aggregate '}} (it adds a space) and does not show me the
> list of available aggregates. If I type {{'desc aggregate .'}}
> (note the trailing full stop) and hit tab, auto-complete will work correctly.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10733) Inconsistencies in CQLSH auto-complete
[
https://issues.apache.org/jira/browse/CASSANDRA-10733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15015602#comment-15015602
]
Michael Edge commented on CASSANDRA-10733:
--
Need some advice on the second issue in this JIRA from someone more familiar
with cqlsh. The problem is caused by this piece of code (see code between ):
{{cqlhandling.py}}
{code}
def cql_complete_multiple(self, text, first, init_bindings,
startsymbol='Start'):
debug = init_bindings.get('*DEBUG*', True)
try:
completions, hints = self.cql_complete_single(text + first, '',
init_bindings,
startsymbol=startsymbol)
except Exception:
if debug:
print "** completion expansion had a problem:"
traceback.print_exc()
return first
if hints:
if not first[-1].isspace():
first += ' '
if debug:
print "** completion expansion found hints: %r. First: %r." %
(hints,first,)
return first
{code}
This code adds a space onto an auto-completed clause, which is fine;
unfortunately it also adds a space onto a partially completed clause, which is
causing the problem. I could remove this, or only apply it if the clause is
complete (not partially complete), but I don't know whether it would impact any
other components.
h3. To replicate the issue do the following:
In a keyspace with no functions (let's call the keyspace 'shopping'), create
two functions with the same prefix; for example, 'avgstate' and 'avgfinal'.
There are now 2 functions in keyspace 'shopping'. Then in cqlsh type {{'desc
function sho'}} and hit the tab key. cqlsh should complete the clause and show
{{'desc function shopping.avg'}}. A further tab would display the two matching
functions.
Instead it displays {{'desc function shopping.avg '}} (note the trailing
space). A further tab does not display the matching functions.
> Inconsistencies in CQLSH auto-complete
> --
>
> Key: CASSANDRA-10733
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10733
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL, Tools
>Reporter: Michael Edge
>Assignee: Michael Edge
>Priority: Trivial
> Labels: cqlsh, lhf
> Fix For: 2.1.x, 2.2.x, 3.x
>
> Attachments: CASSANDRA-3.0-10733-CQLSH-Auto.patch
>
>
> Auto-complete in cqlsh does not work correctly on some commands. We see some
> inconsistent behaviour when completing part of the statement and hitting the
> tab key.
> {color:green}Works correctly{color}
> Auto-complete on {{'desc table '}}, {{'desc function '}} and {{'desc type '}}
> works correctly. We see a list of all tables (or functions, types) in the
> current keyspace plus a list of all available keyspaces followed by a full
> stop (e.g. system.)
> {code}
> cqlsh:fxaggr> desc TABLE
> minutedata system_distributed.
> ;rawtickdatabylp system_traces.
> rawtickdatabysymbol tickdata
> daydata system.
> fxaggr. system_auth.
> {code}
> {color:red}Fix required{color}
> {{'desc aggregate '}} displays the aggregates in the current keyspace (in
> this case, only 1, called 'average') but does not display a list of available
> keyspaces. It only displays the current keyspace, with no following full stop.
> {code}
> cqlsh:fxaggr> desc aggregate
> ; average fxaggr
> {code}
> {color:green}Works correctly{color}
> Auto-complete on {{'desc table . '}} and {{'desc type
> .'}} works correctly. We see a list of all tables (or types) in the
> current keyspace
> {code}
> cqlsh:fxaggr> desc table fxaggr.
> daydata rawtickdatabylp tickdata
> minutedata rawtickdatabysymbol
> {code}
> {color:red}Fix required{color}
> Auto-complete on {{'desc function . '}} and {{'desc aggregate
> .'}} works inconsistently. In a keyspace with 2 functions, both
> beginning with the letters 'avg', if I type {{'desc function '}}
> and hit tab, auto-complete will result in this: {{'desc function fxaggr.avg
> '}} and will not display the matching functions. If I type {{'desc function
> .'}} (note the trailing full stop) and hit tab, auto-complete will
> work correctly:
> {code}
> cqlsh:fxaggr> desc function fxaggr.avg
> avgfinal avgstate
> {code}
> If I type {{'desc aggregate '}} and hit tab, auto-complete returns
> {{'desc aggregate '}} (it adds a space) and does not show me the
> list of available aggregates. If I type {{'desc aggregate .'}}
> (note the trailing full stop) and hit
[jira] [Updated] (CASSANDRA-10733) Inconsistencies in CQLSH auto-complete
[
https://issues.apache.org/jira/browse/CASSANDRA-10733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Edge updated CASSANDRA-10733:
-
Attachment: CASSANDRA-3.0-10733-CQLSH-Auto.patch
Patch to fix first of the two issues mentioned in this JIRA.
> Inconsistencies in CQLSH auto-complete
> --
>
> Key: CASSANDRA-10733
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10733
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL, Tools
>Reporter: Michael Edge
>Assignee: Michael Edge
>Priority: Trivial
> Labels: cqlsh, lhf
> Fix For: 2.1.x, 2.2.x, 3.x
>
> Attachments: CASSANDRA-3.0-10733-CQLSH-Auto.patch
>
>
> Auto-complete in cqlsh does not work correctly on some commands. We see some
> inconsistent behaviour when completing part of the statement and hitting the
> tab key.
> {color:green}Works correctly{color}
> Auto-complete on {{'desc table '}}, {{'desc function '}} and {{'desc type '}}
> works correctly. We see a list of all tables (or functions, types) in the
> current keyspace plus a list of all available keyspaces followed by a full
> stop (e.g. system.)
> {code}
> cqlsh:fxaggr> desc TABLE
> minutedata system_distributed.
> ;rawtickdatabylp system_traces.
> rawtickdatabysymbol tickdata
> daydata system.
> fxaggr. system_auth.
> {code}
> {color:red}Fix required{color}
> {{'desc aggregate '}} displays the aggregates in the current keyspace (in
> this case, only 1, called 'average') but does not display a list of available
> keyspaces. It only displays the current keyspace, with no following full stop.
> {code}
> cqlsh:fxaggr> desc aggregate
> ; average fxaggr
> {code}
> {color:green}Works correctly{color}
> Auto-complete on {{'desc table . '}} and {{'desc type
> .'}} works correctly. We see a list of all tables (or types) in the
> current keyspace
> {code}
> cqlsh:fxaggr> desc table fxaggr.
> daydata rawtickdatabylp tickdata
> minutedata rawtickdatabysymbol
> {code}
> {color:red}Fix required{color}
> Auto-complete on {{'desc function . '}} and {{'desc aggregate
> .'}} works inconsistently. In a keyspace with 2 functions, both
> beginning with the letters 'avg', if I type {{'desc function '}}
> and hit tab, auto-complete will result in this: {{'desc function fxaggr.avg
> '}} and will not display the matching functions. If I type {{'desc function
> .'}} (note the trailing full stop) and hit tab, auto-complete will
> work correctly:
> {code}
> cqlsh:fxaggr> desc function fxaggr.avg
> avgfinal avgstate
> {code}
> If I type {{'desc aggregate '}} and hit tab, auto-complete returns
> {{'desc aggregate '}} (it adds a space) and does not show me the
> list of available aggregates. If I type {{'desc aggregate .'}}
> (note the trailing full stop) and hit tab, auto-complete will work correctly.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10733) Inconsistencies in CQLSH auto-complete
[
https://issues.apache.org/jira/browse/CASSANDRA-10733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Edge updated CASSANDRA-10733:
-
Component/s: CQL
> Inconsistencies in CQLSH auto-complete
> --
>
> Key: CASSANDRA-10733
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10733
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL, Tools
>Reporter: Michael Edge
>Assignee: Michael Edge
>Priority: Trivial
> Labels: cqlsh, lhf
> Fix For: 2.1.x, 2.2.x, 3.x
>
>
> Auto-complete in cqlsh does not work correctly on some commands. We see some
> inconsistent behaviour when completing part of the statement and hitting the
> tab key.
> {color:green}Works correctly{color}
> Auto-complete on {{'desc table '}}, {{'desc function '}} and {{'desc type '}}
> works correctly. We see a list of all tables (or functions, types) in the
> current keyspace plus a list of all available keyspaces followed by a full
> stop (e.g. system.)
> {code}
> cqlsh:fxaggr> desc TABLE
> minutedata system_distributed.
> ;rawtickdatabylp system_traces.
> rawtickdatabysymbol tickdata
> daydata system.
> fxaggr. system_auth.
> {code}
> {color:red}Fix required{color}
> {{'desc aggregate '}} displays the aggregates in the current keyspace (in
> this case, only 1, called 'average') but does not display a list of available
> keyspaces. It only displays the current keyspace, with no following full stop.
> {code}
> cqlsh:fxaggr> desc aggregate
> ; average fxaggr
> {code}
> {color:green}Works correctly{color}
> Auto-complete on {{'desc table . '}} and {{'desc type
> .'}} works correctly. We see a list of all tables (or types) in the
> current keyspace
> {code}
> cqlsh:fxaggr> desc table fxaggr.
> daydata rawtickdatabylp tickdata
> minutedata rawtickdatabysymbol
> {code}
> {color:red}Fix required{color}
> Auto-complete on {{'desc function . '}} and {{'desc aggregate
> .'}} works inconsistently. In a keyspace with 2 functions, both
> beginning with the letters 'avg', if I type {{'desc function '}}
> and hit tab, auto-complete will result in this: {{'desc function fxaggr.avg
> '}} and will not display the matching functions. If I type {{'desc function
> .'}} (note the trailing full stop) and hit tab, auto-complete will
> work correctly:
> {code}
> cqlsh:fxaggr> desc function fxaggr.avg
> avgfinal avgstate
> {code}
> If I type {{'desc aggregate '}} and hit tab, auto-complete returns
> {{'desc aggregate '}} (it adds a space) and does not show me the
> list of available aggregates. If I type {{'desc aggregate .'}}
> (note the trailing full stop) and hit tab, auto-complete will work correctly.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10719) Inconsistencies within CQL 'describe', and CQL docs/'help describe'
[ https://issues.apache.org/jira/browse/CASSANDRA-10719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Edge updated CASSANDRA-10719: - Component/s: Tools > Inconsistencies within CQL 'describe', and CQL docs/'help describe' > --- > > Key: CASSANDRA-10719 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10719 > Project: Cassandra > Issue Type: Improvement > Components: CQL, Documentation and Website, Tools >Reporter: Michael Edge >Assignee: Michael Edge >Priority: Minor > Labels: cqlsh, doc-impacting, docs > Fix For: 2.1.x, 2.2.x, 3.x > > Attachments: CASSANDRA-2.1-10719-Describe.patch, > CASSANDRA-2.2-10719-Describe.patch, CASSANDRA-3.0-10719-Describe.patch > > > While investigating the issue CASSANDRA-9678 I noticed a number of > inconsistencies in the way 'describe' operates, so I'm opening a new issue to > address these. This issue will also address CASSANDRA-9678. > I'd be happy to work on this. > There are a number of inconsistencies in the way 'describe' operates within > cqlsh, and also in the 'help describe' description within cqlsh compared to > the CQL documentation (at > http://docs.datastax.com/en/cql/3.3/cql/cql_reference/describe_r1.html) > For example, 'desc functions' will list all functions for all keyspaces > regardless of whether there is a current keyspace or not, whereas 'desc > tables' or 'desc types' will list only the tables or types for the current > keyspace. > Some commands exist in cqlsh that are not in the CQL documentation, nor in > the 'help describe' description. For example, 'desc functions' is a valid > CQLSH command but does not appear in either the CQL docs or 'help describe'. > I suggest we align the way the 'describe' command works so that it works > consistently regardless of whether it is describing a table, type, function > or any other database object, and also update the CQL and 'help describe' > docs to match. Since 'describe tables' and it's variants has been around the > longest we should probably align other 'describe' commands to 'describe > tables'. > My preliminary analysis has shown at least the following inconsistencies: > - 'desc functions' (with current keyspace), differs from 'desc tables' and > 'desc types'. > - a number of commands are missing from the CQL docs or 'help describe, such > as: desc table ., desc functions (no current keyspace), > desc function , desc type ., etc. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10733) Inconsistencies in CQLSH auto-complete
[
https://issues.apache.org/jira/browse/CASSANDRA-10733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Edge updated CASSANDRA-10733:
-
Reproduced In: 2.2.3
> Inconsistencies in CQLSH auto-complete
> --
>
> Key: CASSANDRA-10733
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10733
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Michael Edge
>Assignee: Michael Edge
>Priority: Trivial
> Labels: cqlsh, lhf
> Fix For: 2.1.x, 2.2.x, 3.x
>
>
> Auto-complete in cqlsh does not work correctly on some commands. We see some
> inconsistent behaviour when completing part of the statement and hitting the
> tab key.
> {color:green}Works correctly{color}
> Auto-complete on {{'desc table '}}, {{'desc function '}} and {{'desc type '}}
> works correctly. We see a list of all tables (or functions, types) in the
> current keyspace plus a list of all available keyspaces followed by a full
> stop (e.g. system.)
> {code}
> cqlsh:fxaggr> desc TABLE
> minutedata system_distributed.
> ;rawtickdatabylp system_traces.
> rawtickdatabysymbol tickdata
> daydata system.
> fxaggr. system_auth.
> {code}
> {color:red}Fix required{color}
> {{'desc aggregate '}} displays the aggregates in the current keyspace (in
> this case, only 1, called 'average') but does not display a list of available
> keyspaces. It only displays the current keyspace, with no following full stop.
> {code}
> cqlsh:fxaggr> desc aggregate
> ; average fxaggr
> {code}
> {color:green}Works correctly{color}
> Auto-complete on {{'desc table . '}} and {{'desc type
> .'}} works correctly. We see a list of all tables (or types) in the
> current keyspace
> {code}
> cqlsh:fxaggr> desc table fxaggr.
> daydata rawtickdatabylp tickdata
> minutedata rawtickdatabysymbol
> {code}
> {color:red}Fix required{color}
> Auto-complete on {{'desc function . '}} and {{'desc aggregate
> .'}} works inconsistently. In a keyspace with 2 functions, both
> beginning with the letters 'avg', if I type {{'desc function '}}
> and hit tab, auto-complete will result in this: {{'desc function fxaggr.avg
> '}} and will not display the matching functions. If I type {{'desc function
> .'}} (note the trailing full stop) and hit tab, auto-complete will
> work correctly:
> {code}
> cqlsh:fxaggr> desc function fxaggr.avg
> avgfinal avgstate
> {code}
> If I type {{'desc aggregate '}} and hit tab, auto-complete returns
> {{'desc aggregate '}} (it adds a space) and does not show me the
> list of available aggregates. If I type {{'desc aggregate .'}}
> (note the trailing full stop) and hit tab, auto-complete will work correctly.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10733) Inconsistencies in CQLSH auto-complete
[
https://issues.apache.org/jira/browse/CASSANDRA-10733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Edge updated CASSANDRA-10733:
-
Description:
Auto-complete in cqlsh does not work correctly on some commands. We see some
inconsistent behaviour when completing part of the statement and hitting the
tab key.
{color:green}Works correctly{color}
Auto-complete on {{'desc table '}}, {{'desc function '}} and {{'desc type '}}
works correctly. We see a list of all tables (or functions, types) in the
current keyspace plus a list of all available keyspaces followed by a full stop
(e.g. system.)
{code}
cqlsh:fxaggr> desc TABLE
minutedata system_distributed.
;rawtickdatabylp system_traces.
rawtickdatabysymbol tickdata
daydata system.
fxaggr. system_auth.
{code}
{color:red}Fix required{color}
{{'desc aggregate '}} displays the aggregates in the current keyspace (in this
case, only 1, called 'average') but does not display a list of available
keyspaces. It only displays the current keyspace, with no following full stop.
{code}
cqlsh:fxaggr> desc aggregate
; average fxaggr
{code}
{color:green}Works correctly{color}
Auto-complete on {{'desc table . '}} and {{'desc type .'}}
works correctly. We see a list of all tables (or types) in the current keyspace
{code}
cqlsh:fxaggr> desc table fxaggr.
daydata rawtickdatabylp tickdata
minutedata rawtickdatabysymbol
{code}
{color:red}Fix required{color}
Auto-complete on {{'desc function . '}} and {{'desc aggregate
.'}} works inconsistently. In a keyspace with 2 functions, both
beginning with the letters 'avg', if I type {{'desc function '}} and
hit tab, auto-complete will result in this: {{'desc function fxaggr.avg '}} and
will not display the matching functions. If I type {{'desc function
.'}} (note the trailing full stop) and hit tab, auto-complete will
work correctly:
{code}
cqlsh:fxaggr> desc function fxaggr.avg
avgfinal avgstate
{code}
If I type {{'desc aggregate '}} and hit tab, auto-complete returns
{{'desc aggregate '}} (it adds a space) and does not show me the
list of available aggregates. If I type {{'desc aggregate .'}} (note
the trailing full stop) and hit tab, auto-complete will work correctly.
was:
Auto-complete does not work correctly on some commands. For example:
{color:green}Works correctly{color}
Auto-complete on {{'desc table '}}, {{'desc function '}} and {{'desc type '}}
works correctly. We see a list of all tables (or functions, types) in the
current keyspace plus a list of all available keyspaces followed by a full stop
(e.g. system.)
{code}
cqlsh:fxaggr> desc TABLE
minutedata system_distributed.
;rawtickdatabylp system_traces.
rawtickdatabysymbol tickdata
daydata system.
fxaggr. system_auth.
{code}
{color:red}Fix required{color}
{{'desc aggregate '}} displays the aggregates in the current keyspace (in this
case, only 1, called 'average') but does not display a list of available
keyspaces. It only displays the current keyspace, with no following full stop.
{code}
cqlsh:fxaggr> desc aggregate
; average fxaggr
{code}
{color:green}Works correctly{color}
Auto-complete on {{'desc table . '}} and {{'desc type .'}}
works correctly. We see a list of all tables (or types) in the current keyspace
{code}
cqlsh:fxaggr> desc table fxaggr.
daydata rawtickdatabylp tickdata
minutedata rawtickdatabysymbol
{code}
{color:red}Fix required{color}
Auto-complete on {{'desc function . '}} and {{'desc aggregate
.'}} works inconsistently. In a keyspace with 2 functions, both
beginning with the letters 'avg', if I type {{'desc function '}} and
hit tab, auto-complete will result in this: {{'desc function fxaggr.avg '}} and
will not display the matching functions. If I type {{'desc function
.'}} (note the trailing full stop) and hit tab, auto-complete will
work correctly:
{code}
cqlsh:fxaggr> desc function fxaggr.avg
avgfinal avgstate
{code}
If I type {{'desc aggregate '}} and hit tab, auto-complete returns
{{'desc aggregate '}} (it adds a space) and does not show me the
list of available aggregates. If I type {{'desc aggregate .'}} (note
the trailing full stop) and hit tab, auto-complete will work correctly.
> Inconsistencies in CQLSH auto-complete
> --
>
> Key: CASSANDRA-10733
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10733
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Michael Edge
>Assignee: Michael Edge
>Priority: Trivial
> Labels: cqlsh, lhf
>
[jira] [Updated] (CASSANDRA-10733) Inconsistencies in CQLSH auto-complete
[
https://issues.apache.org/jira/browse/CASSANDRA-10733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Edge updated CASSANDRA-10733:
-
Labels: cqlsh lhf (was: cqlsh)
> Inconsistencies in CQLSH auto-complete
> --
>
> Key: CASSANDRA-10733
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10733
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Michael Edge
>Assignee: Michael Edge
>Priority: Trivial
> Labels: cqlsh, lhf
> Fix For: 2.1.x, 2.2.x, 3.x
>
>
> Auto-complete does not work correctly on some commands. For example:
> {color:green}Works correctly{color}
> Auto-complete on {{'desc table '}}, {{'desc function '}} and {{'desc type '}}
> works correctly. We see a list of all tables (or functions, types) in the
> current keyspace plus a list of all available keyspaces followed by a full
> stop (e.g. system.)
> {code}
> cqlsh:fxaggr> desc TABLE
> minutedata system_distributed.
> ;rawtickdatabylp system_traces.
> rawtickdatabysymbol tickdata
> daydata system.
> fxaggr. system_auth.
> {code}
> {color:red}Fix required{color}
> {{'desc aggregate '}} displays the aggregates in the current keyspace (in
> this case, only 1, called 'average') but does not display a list of available
> keyspaces. It only displays the current keyspace, with no following full stop.
> {code}
> cqlsh:fxaggr> desc aggregate
> ; average fxaggr
> {code}
> {color:green}Works correctly{color}
> Auto-complete on {{'desc table . '}} and {{'desc type
> .'}} works correctly. We see a list of all tables (or types) in the
> current keyspace
> {code}
> cqlsh:fxaggr> desc table fxaggr.
> daydata rawtickdatabylp tickdata
> minutedata rawtickdatabysymbol
> {code}
> {color:red}Fix required{color}
> Auto-complete on {{'desc function . '}} and {{'desc aggregate
> .'}} works inconsistently. In a keyspace with 2 functions, both
> beginning with the letters 'avg', if I type {{'desc function '}}
> and hit tab, auto-complete will result in this: {{'desc function fxaggr.avg
> '}} and will not display the matching functions. If I type {{'desc function
> .'}} (note the trailing full stop) and hit tab, auto-complete will
> work correctly:
> {code}
> cqlsh:fxaggr> desc function fxaggr.avg
> avgfinal avgstate
> {code}
> If I type {{'desc aggregate '}} and hit tab, auto-complete returns
> {{'desc aggregate '}} (it adds a space) and does not show me the
> list of available aggregates. If I type {{'desc aggregate .'}}
> (note the trailing full stop) and hit tab, auto-complete will work correctly.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10733) Inconsistencies in CQLSH auto-complete
[
https://issues.apache.org/jira/browse/CASSANDRA-10733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Edge updated CASSANDRA-10733:
-
Description:
Auto-complete does not work correctly on some commands. For example:
{color:green}Works correctly{color}
Auto-complete on {{'desc table '}}, {{'desc function '}} and {{'desc type '}}
works correctly. We see a list of all tables (or functions, types) in the
current keyspace plus a list of all available keyspaces followed by a full stop
(e.g. system.)
{code}
cqlsh:fxaggr> desc TABLE
minutedata system_distributed.
;rawtickdatabylp system_traces.
rawtickdatabysymbol tickdata
daydata system.
fxaggr. system_auth.
{code}
{color:red}Fix required{color}
{{'desc aggregate '}} displays the aggregates in the current keyspace (in this
case, only 1, called 'average') but does not display a list of available
keyspaces. It only displays the current keyspace, with no following full stop.
{code}
cqlsh:fxaggr> desc aggregate
; average fxaggr
{code}
{color:green}Works correctly{color}
Auto-complete on {{'desc table . '}} and {{'desc type .'}}
works correctly. We see a list of all tables (or types) in the current keyspace
{code}
cqlsh:fxaggr> desc table fxaggr.
daydata rawtickdatabylp tickdata
minutedata rawtickdatabysymbol
{code}
{color:red}Fix required{color}
Auto-complete on {{'desc function . '}} and {{'desc aggregate
.'}} works inconsistently. In a keyspace with 2 functions, both
beginning with the letters 'avg', if I type {{'desc function '}} and
hit tab, auto-complete will result in this: {{'desc function fxaggr.avg '}} and
will not display the matching functions. If I type {{'desc function
.'}} (note the trailing full stop) and hit tab, auto-complete will
work correctly:
{code}
cqlsh:fxaggr> desc function fxaggr.avg
avgfinal avgstate
{code}
If I type {{'desc aggregate '}} and hit tab, auto-complete returns
{{'desc aggregate '}} (it adds a space) and does not show me the
list of available aggregates. If I type {{'desc aggregate .'}} (note
the trailing full stop) and hit tab, auto-complete will work correctly.
was:
Auto-complete does not work correctly on some commands. For example:
Auto-complete on {{'desc table '}}, {{'desc function '}} and {{'desc type '}}
works correctly. We see a list of all tables (or functions, types) in the
current keyspace plus a list of all available keyspaces followed by a full stop
(e.g. system.)
{color:green}works correctly{color}
{code}
cqlsh:fxaggr> desc TABLE
minutedata system_distributed.
;rawtickdatabylp system_traces.
rawtickdatabysymbol tickdata
daydata system.
fxaggr. system_auth.
{code}
{{'desc aggregate '}} displays the aggregates in the current keyspace (in this
case, only 1, called 'average') but does not display a list of available
keyspaces. It only displays the current keyspace, with no following full stop.
{code}
{color:red}fix required{color}
cqlsh:fxaggr> desc aggregate
; average fxaggr
{code}
Auto-complete on {{'desc table . '}} and {{'desc type .'}}
works correctly. We see a list of all tables (or types) in the current keyspace
{color:green}works correctly{color}
{code}
cqlsh:fxaggr> desc table fxaggr.
daydata rawtickdatabylp tickdata
minutedata rawtickdatabysymbol
{code}
Auto-complete on {{'desc function . '}} and {{'desc aggregate
.'}} works inconsistently. In a keyspace with 2 functions, both
beginning with the letters 'avg', if I type {{'desc function '}} and
hit tab, auto-complete will result in this: {{'desc function fxaggr.avg '}} and
will not display the matching functions. If I type {{'desc function
.'}} (note the trailing full stop) and hit tab, auto-complete will
work correctly:
{color:red}fix required{color}
{code}
cqlsh:fxaggr> desc function fxaggr.avg
avgfinal avgstate
{code}
If I type {{'desc aggregate '}} and hit tab, auto-complete returns
{{'desc aggregate '}} (it adds a space) and does not show me the
list of available aggregates. If I type {{'desc aggregate .'}} (note
the trailing full stop) and hit tab, auto-complete will work correctly.
> Inconsistencies in CQLSH auto-complete
> --
>
> Key: CASSANDRA-10733
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10733
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Michael Edge
>Assignee: Michael Edge
>Priority: Trivial
> Labels: cqlsh, lhf
> Fix For: 2.1.x, 2.2.x, 3.x
>
>
> Auto-complete does not work correctly on some commands. For examp
[jira] [Updated] (CASSANDRA-10733) Inconsistencies in CQLSH auto-complete
[
https://issues.apache.org/jira/browse/CASSANDRA-10733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Edge updated CASSANDRA-10733:
-
Description:
Auto-complete does not work correctly on some commands. For example:
Auto-complete on {{'desc table '}}, {{'desc function '}} and {{'desc type '}}
works correctly. We see a list of all tables (or functions, types) in the
current keyspace plus a list of all available keyspaces followed by a full stop
(e.g. system.)
{color:green}works correctly{color}
{code}
cqlsh:fxaggr> desc TABLE
minutedata system_distributed.
;rawtickdatabylp system_traces.
rawtickdatabysymbol tickdata
daydata system.
fxaggr. system_auth.
{code}
{{'desc aggregate '}} displays the aggregates in the current keyspace (in this
case, only 1, called 'average') but does not display a list of available
keyspaces. It only displays the current keyspace, with no following full stop.
{code}
{color:red}fix required{color}
cqlsh:fxaggr> desc aggregate
; average fxaggr
{code}
Auto-complete on {{'desc table . '}} and {{'desc type .'}}
works correctly. We see a list of all tables (or types) in the current keyspace
{color:green}works correctly{color}
{code}
cqlsh:fxaggr> desc table fxaggr.
daydata rawtickdatabylp tickdata
minutedata rawtickdatabysymbol
{code}
Auto-complete on {{'desc function . '}} and {{'desc aggregate
.'}} works inconsistently. In a keyspace with 2 functions, both
beginning with the letters 'avg', if I type {{'desc function '}} and
hit tab, auto-complete will result in this: {{'desc function fxaggr.avg '}} and
will not display the matching functions. If I type {{'desc function
.'}} (note the trailing full stop) and hit tab, auto-complete will
work correctly:
{color:red}fix required{color}
{code}
cqlsh:fxaggr> desc function fxaggr.avg
avgfinal avgstate
{code}
If I type {{'desc aggregate '}} and hit tab, auto-complete returns
{{'desc aggregate '}} (it adds a space) and does not show me the
list of available aggregates. If I type {{'desc aggregate .'}} (note
the trailing full stop) and hit tab, auto-complete will work correctly.
was:
Auto-complete does not work correctly on some commands. For example:
Auto-complete on {{'desc table '}}, {{'desc function '}} and {{'desc type '}}
works correctly. We see a list of all tables (or functions, types) in the
current keyspace plus a list of all available keyspaces followed by a full stop
(e.g. system.)
{code}
cqlsh:fxaggr> desc TABLE
minutedata system_distributed.
;rawtickdatabylp system_traces.
rawtickdatabysymbol tickdata
daydata system.
fxaggr. system_auth.
{code}
{{'desc aggregate '}} displays the aggregates in the current keyspace (in this
case, only 1, called 'average') but does not display a list of available
keyspaces. It only displays the current keyspace, with no following full stop.
{code}
cqlsh:fxaggr> desc aggregate
; average fxaggr
{code}
Auto-complete on {{'desc table . '}} and {{'desc type .'}}
works correctly. We see a list of all tables (or types) in the current keyspace
{code}
cqlsh:fxaggr> desc table fxaggr.
daydata rawtickdatabylp tickdata
minutedata rawtickdatabysymbol
{code}
Auto-complete on {{'desc function . '}} and {{'desc aggregate
.'}} works inconsistently. In a keyspace with 2 functions, both
beginning with the letters 'avg', if I type {{'desc function '}} and
hit tab, auto-complete will result in this: {{'desc function fxaggr.avg '}} and
will not display the matching functions. If I type {{'desc function
.'}} (note the trailing full stop) and hit tab, auto-complete will
work correctly:
{code}
cqlsh:fxaggr> desc function fxaggr.avg
avgfinal avgstate
{code}
If I type {{'desc aggregate '}} and hit tab, auto-complete returns
{{'desc aggregate '}} (it adds a space) and does not show me the
list of available aggregates. If I type {{'desc aggregate .'}} (note
the trailing full stop) and hit tab, auto-complete will work correctly.
> Inconsistencies in CQLSH auto-complete
> --
>
> Key: CASSANDRA-10733
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10733
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Michael Edge
>Assignee: Michael Edge
>Priority: Trivial
> Labels: cqlsh
> Fix For: 2.1.x, 2.2.x, 3.x
>
>
> Auto-complete does not work correctly on some commands. For example:
> Auto-complete on {{'desc table '}}, {{'desc function '}} and {{'desc type '}}
> works correctly. We see a list of all tables (or functions,
[jira] [Updated] (CASSANDRA-10733) Inconsistencies in CQLSH auto-complete
[
https://issues.apache.org/jira/browse/CASSANDRA-10733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Edge updated CASSANDRA-10733:
-
Description:
Auto-complete does not work correctly on some commands. For example:
Auto-complete on {{'desc table '}}, {{'desc function '}} and {{'desc type '}}
works correctly. We see a list of all tables (or functions, types) in the
current keyspace plus a list of all available keyspaces followed by a full stop
(e.g. system.)
{code}
cqlsh:fxaggr> desc TABLE
minutedata system_distributed.
;rawtickdatabylp system_traces.
rawtickdatabysymbol tickdata
daydata system.
fxaggr. system_auth.
{code}
{{'desc aggregate '}} displays the aggregates in the current keyspace (in this
case, only 1, called 'average') but does not display a list of available
keyspaces. It only displays the current keyspace, with no following full stop.
{code}
cqlsh:fxaggr> desc aggregate
; average fxaggr
{code}
Auto-complete on {{'desc table . '}} and {{'desc type .'}}
works correctly. We see a list of all tables (or types) in the current keyspace
{code}
cqlsh:fxaggr> desc table fxaggr.
daydata rawtickdatabylp tickdata
minutedata rawtickdatabysymbol
{code}
Auto-complete on {{'desc function . '}} and {{'desc aggregate
.'}} works inconsistently. In a keyspace with 2 functions, both
beginning with the letters 'avg', if I type {{'desc function '}} and
hit tab, auto-complete will result in this: {{'desc function fxaggr.avg '}} and
will not display the matching functions. If I type {{'desc function
.'}} (note the trailing full stop) and hit tab, auto-complete will
work correctly:
{code}
cqlsh:fxaggr> desc function fxaggr.avg
avgfinal avgstate
{code}
If I type {{'desc aggregate '}} and hit tab, auto-complete returns
{{'desc aggregate '}} (it adds a space) and does not show me the
list of available aggregates. If I type {{'desc aggregate .'}} (note
the trailing full stop) and hit tab, auto-complete will work correctly.
was:
Auto-complete does not work correctly on some commands. For example:
Auto-complete on {{'desc table '}}, {{'desc function '}} and {{'desc type '}}
works correctly. We see a list of all tables (or functions, types) in the
current keyspace plus a list of all available keyspaces followed by a full stop
(e.g. system.)
{code}
cqlsh:fxaggr> desc TABLE
minutedata system_distributed.
;rawtickdatabylp system_traces.
rawtickdatabysymbol tickdata
daydata system.
fxaggr. system_auth.
{code}
{{'desc aggregate '}} displays the aggregates in the current keyspace (in this
case, only 1, called 'average') but does not display a list of available
keyspaces. It only displays the current keyspace, with no following full stop.
{code}
cqlsh:fxaggr> desc aggregate
; average fxaggr
{code}
Auto-complete on {{'desc table . '}} and {{'desc type .'}}
works correctly. We see a list of all tables (or types) in the current keyspace
cqlsh:fxaggr> desc table fxaggr.
daydata rawtickdatabylp tickdata
minutedata rawtickdatabysymbol
Auto-complete on {{'desc function . '}} and {{'desc aggregate
.'}} works inconsistently. In a keyspace with 2 functions, both
beginning with the letters 'avg', if I type {{'desc function '}} and
hit tab, auto-complete will result in this: {{'desc function fxaggr.avg '}} and
will not display the matching functions. If I type {{'desc function
.'}} (note the trailing full stop) and hit tab, auto-complete will
work correctly:
{code}
cqlsh:fxaggr> desc function fxaggr.avg
avgfinal avgstate
{code}
If I type {{'desc aggregate '}} and hit tab, auto-complete returns
{{'desc aggregate '}} (it adds a space) and does not show me the
list of available aggregates. If I type {{'desc aggregate .'}} (note
the trailing full stop) and hit tab, auto-complete will work correctly.
> Inconsistencies in CQLSH auto-complete
> --
>
> Key: CASSANDRA-10733
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10733
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Michael Edge
>Assignee: Michael Edge
>Priority: Trivial
> Labels: cqlsh
> Fix For: 2.1.x, 2.2.x, 3.x
>
>
> Auto-complete does not work correctly on some commands. For example:
> Auto-complete on {{'desc table '}}, {{'desc function '}} and {{'desc type '}}
> works correctly. We see a list of all tables (or functions, types) in the
> current keyspace plus a list of all available keyspaces followed by a full
> stop (e.g. system.)
> {code}
> cqlsh:fxaggr> desc
[jira] [Updated] (CASSANDRA-10733) Inconsistencies in CQLSH auto-complete
[
https://issues.apache.org/jira/browse/CASSANDRA-10733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Edge updated CASSANDRA-10733:
-
Description:
Auto-complete does not work correctly on some commands. For example:
Auto-complete on {{'desc table '}}, {{'desc function '}} and {{'desc type '}}
works correctly. We see a list of all tables (or functions, types) in the
current keyspace plus a list of all available keyspaces followed by a full stop
(e.g. system.)
{code}
cqlsh:fxaggr> desc TABLE
minutedata system_distributed.
;rawtickdatabylp system_traces.
rawtickdatabysymbol tickdata
daydata system.
fxaggr. system_auth.
{code}
{{'desc aggregate '}} displays the aggregates in the current keyspace (in this
case, only 1, called 'average') but does not display a list of available
keyspaces. It only displays the current keyspace, with no following full stop.
{code}
cqlsh:fxaggr> desc aggregate
; average fxaggr
{code}
Auto-complete on {{'desc table . '}} and {{'desc type .'}}
works correctly. We see a list of all tables (or types) in the current keyspace
cqlsh:fxaggr> desc table fxaggr.
daydata rawtickdatabylp tickdata
minutedata rawtickdatabysymbol
Auto-complete on {{'desc function . '}} and {{'desc aggregate
.'}} works inconsistently. In a keyspace with 2 functions, both
beginning with the letters 'avg', if I type {{'desc function '}} and
hit tab, auto-complete will result in this: {{'desc function fxaggr.avg '}} and
will not display the matching functions. If I type {{'desc function
.'}} (note the trailing full stop) and hit tab, auto-complete will
work correctly:
{code}
cqlsh:fxaggr> desc function fxaggr.avg
avgfinal avgstate
{code}
If I type {{'desc aggregate '}} and hit tab, auto-complete returns
{{'desc aggregate '}} (it adds a space) and does not show me the
list of available aggregates. If I type {{'desc aggregate .'}} (note
the trailing full stop) and hit tab, auto-complete will work correctly.
was:
Auto-complete does not work correctly on some commands. For example:
Auto-complete on 'desc table ', 'desc function' and 'desc type ' works
correctly. We see a list of all tables (or functions, types) in the current
keyspace plus a list of all available keyspaces followed by a full stop (e.g.
system.)
{{cqlsh:fxaggr> desc TABLE
minutedata system_distributed.
;rawtickdatabylp system_traces.
rawtickdatabysymbol tickdata
daydata system.
fxaggr. system_auth. }}
'desc aggregate' displays the aggregates in the current keyspace (in this case,
only 1, called 'average') but does not display a list of available keyspaces.
It only displays the current keyspace, with no following full stop.
cqlsh:fxaggr> desc aggregate
; average fxaggr
Auto-complete on 'desc table . ' and 'desc type .' works
correctly. We see a list of all tables (or types) in the current keyspace
cqlsh:fxaggr> desc table fxaggr.
daydata rawtickdatabylp tickdata
minutedata rawtickdatabysymbol
Auto-complete on 'desc function . ' and 'desc aggregate .'
works inconsistently. In a keyspace with 2 functions, both beginning with the
letters 'avg', if I type 'desc function ' and hit tab, auto-complete
will result in this: 'desc function fxaggr.avg ' and will not display the
matching functions. If I type 'desc function .' (note the trailing
full stop) and hit tab, auto-complete will work correctly:
cqlsh:fxaggr> desc function fxaggr.avg
avgfinal avgstate
If I type 'desc aggregate ' and hit tab, auto-complete returns 'desc
aggregate ' (it adds a space) and does not show me the list of
available aggregates. If I type 'desc aggregate .' (note the trailing
full stop) and hit tab, auto-complete will work correctly.
> Inconsistencies in CQLSH auto-complete
> --
>
> Key: CASSANDRA-10733
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10733
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Michael Edge
>Assignee: Michael Edge
>Priority: Trivial
> Labels: cqlsh
> Fix For: 2.1.x, 2.2.x, 3.x
>
>
> Auto-complete does not work correctly on some commands. For example:
> Auto-complete on {{'desc table '}}, {{'desc function '}} and {{'desc type '}}
> works correctly. We see a list of all tables (or functions, types) in the
> current keyspace plus a list of all available keyspaces followed by a full
> stop (e.g. system.)
> {code}
> cqlsh:fxaggr> desc TABLE
> minutedata system_distributed.
> ;rawti
[jira] [Updated] (CASSANDRA-10733) Inconsistencies in CQLSH auto-complete
[
https://issues.apache.org/jira/browse/CASSANDRA-10733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Edge updated CASSANDRA-10733:
-
Description:
Auto-complete does not work correctly on some commands. For example:
Auto-complete on 'desc table ', 'desc function' and 'desc type ' works
correctly. We see a list of all tables (or functions, types) in the current
keyspace plus a list of all available keyspaces followed by a full stop (e.g.
system.)
{{cqlsh:fxaggr> desc TABLE
minutedata system_distributed.
;rawtickdatabylp system_traces.
rawtickdatabysymbol tickdata
daydata system.
fxaggr. system_auth. }}
'desc aggregate' displays the aggregates in the current keyspace (in this case,
only 1, called 'average') but does not display a list of available keyspaces.
It only displays the current keyspace, with no following full stop.
cqlsh:fxaggr> desc aggregate
; average fxaggr
Auto-complete on 'desc table . ' and 'desc type .' works
correctly. We see a list of all tables (or types) in the current keyspace
cqlsh:fxaggr> desc table fxaggr.
daydata rawtickdatabylp tickdata
minutedata rawtickdatabysymbol
Auto-complete on 'desc function . ' and 'desc aggregate .'
works inconsistently. In a keyspace with 2 functions, both beginning with the
letters 'avg', if I type 'desc function ' and hit tab, auto-complete
will result in this: 'desc function fxaggr.avg ' and will not display the
matching functions. If I type 'desc function .' (note the trailing
full stop) and hit tab, auto-complete will work correctly:
cqlsh:fxaggr> desc function fxaggr.avg
avgfinal avgstate
If I type 'desc aggregate ' and hit tab, auto-complete returns 'desc
aggregate ' (it adds a space) and does not show me the list of
available aggregates. If I type 'desc aggregate .' (note the trailing
full stop) and hit tab, auto-complete will work correctly.
was:
Auto-complete does not work correctly on some commands. For example:
Auto-complete on 'desc table ', 'desc function' and 'desc type ' works
correctly. We see a list of all tables (or functions, types) in the current
keyspace plus a list of all available keyspaces followed by a full stop (e.g.
system.)
cqlsh:fxaggr> desc TABLE
minutedata system_distributed.
;rawtickdatabylp system_traces.
rawtickdatabysymbol tickdata
daydata system.
fxaggr. system_auth.
'desc aggregate' displays the aggregates in the current keyspace (in this case,
only 1, called 'average') but does not display a list of available keyspaces.
It only displays the current keyspace, with no following full stop.
cqlsh:fxaggr> desc aggregate
; average fxaggr
Auto-complete on 'desc table . ' and 'desc type .' works
correctly. We see a list of all tables (or types) in the current keyspace
cqlsh:fxaggr> desc table fxaggr.
daydata rawtickdatabylp tickdata
minutedata rawtickdatabysymbol
Auto-complete on 'desc function . ' and 'desc aggregate .'
works inconsistently. In a keyspace with 2 functions, both beginning with the
letters 'avg', if I type 'desc function ' and hit tab, auto-complete
will result in this: 'desc function fxaggr.avg ' and will not display the
matching functions. If I type 'desc function .' (note the trailing
full stop) and hit tab, auto-complete will work correctly:
cqlsh:fxaggr> desc function fxaggr.avg
avgfinal avgstate
If I type 'desc aggregate ' and hit tab, auto-complete returns 'desc
aggregate ' (it adds a space) and does not show me the list of
available aggregates. If I type 'desc aggregate .' (note the trailing
full stop) and hit tab, auto-complete will work correctly.
> Inconsistencies in CQLSH auto-complete
> --
>
> Key: CASSANDRA-10733
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10733
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Michael Edge
>Assignee: Michael Edge
>Priority: Trivial
> Labels: cqlsh
> Fix For: 2.1.x, 2.2.x, 3.x
>
>
> Auto-complete does not work correctly on some commands. For example:
> Auto-complete on 'desc table ', 'desc function' and 'desc type ' works
> correctly. We see a list of all tables (or functions, types) in the current
> keyspace plus a list of all available keyspaces followed by a full stop (e.g.
> system.)
> {{cqlsh:fxaggr> desc TABLE
> minutedata system_distributed.
> ;rawtickdatabylp system_traces.
> rawtickdatabysymbol tickdata
> daydata system.
[jira] [Created] (CASSANDRA-10733) Inconsistencies in CQLSH auto-complete
Michael Edge created CASSANDRA-10733: Summary: Inconsistencies in CQLSH auto-complete Key: CASSANDRA-10733 URL: https://issues.apache.org/jira/browse/CASSANDRA-10733 Project: Cassandra Issue Type: Improvement Reporter: Michael Edge Assignee: Michael Edge Priority: Trivial Fix For: 2.1.x, 2.2.x, 3.x Auto-complete does not work correctly on some commands. For example: Auto-complete on 'desc table ', 'desc function' and 'desc type ' works correctly. We see a list of all tables (or functions, types) in the current keyspace plus a list of all available keyspaces followed by a full stop (e.g. system.) cqlsh:fxaggr> desc TABLE minutedata system_distributed. ;rawtickdatabylp system_traces. rawtickdatabysymbol tickdata daydata system. fxaggr. system_auth. 'desc aggregate' displays the aggregates in the current keyspace (in this case, only 1, called 'average') but does not display a list of available keyspaces. It only displays the current keyspace, with no following full stop. cqlsh:fxaggr> desc aggregate ; average fxaggr Auto-complete on 'desc table . ' and 'desc type .' works correctly. We see a list of all tables (or types) in the current keyspace cqlsh:fxaggr> desc table fxaggr. daydata rawtickdatabylp tickdata minutedata rawtickdatabysymbol Auto-complete on 'desc function . ' and 'desc aggregate .' works inconsistently. In a keyspace with 2 functions, both beginning with the letters 'avg', if I type 'desc function ' and hit tab, auto-complete will result in this: 'desc function fxaggr.avg ' and will not display the matching functions. If I type 'desc function .' (note the trailing full stop) and hit tab, auto-complete will work correctly: cqlsh:fxaggr> desc function fxaggr.avg avgfinal avgstate If I type 'desc aggregate ' and hit tab, auto-complete returns 'desc aggregate ' (it adds a space) and does not show me the list of available aggregates. If I type 'desc aggregate .' (note the trailing full stop) and hit tab, auto-complete will work correctly. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10719) Inconsistencies within CQL 'describe', and CQL docs/'help describe'
[ https://issues.apache.org/jira/browse/CASSANDRA-10719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Edge updated CASSANDRA-10719: - Fix Version/s: 2.2.x 2.1.x > Inconsistencies within CQL 'describe', and CQL docs/'help describe' > --- > > Key: CASSANDRA-10719 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10719 > Project: Cassandra > Issue Type: Improvement > Components: CQL, Documentation and Website >Reporter: Michael Edge >Assignee: Michael Edge >Priority: Minor > Labels: cqlsh, doc-impacting, docs > Fix For: 2.1.x, 2.2.x, 3.x > > Attachments: CASSANDRA-2.1-10719-Describe.patch, > CASSANDRA-2.2-10719-Describe.patch, CASSANDRA-3.0-10719-Describe.patch > > > While investigating the issue CASSANDRA-9678 I noticed a number of > inconsistencies in the way 'describe' operates, so I'm opening a new issue to > address these. This issue will also address CASSANDRA-9678. > I'd be happy to work on this. > There are a number of inconsistencies in the way 'describe' operates within > cqlsh, and also in the 'help describe' description within cqlsh compared to > the CQL documentation (at > http://docs.datastax.com/en/cql/3.3/cql/cql_reference/describe_r1.html) > For example, 'desc functions' will list all functions for all keyspaces > regardless of whether there is a current keyspace or not, whereas 'desc > tables' or 'desc types' will list only the tables or types for the current > keyspace. > Some commands exist in cqlsh that are not in the CQL documentation, nor in > the 'help describe' description. For example, 'desc functions' is a valid > CQLSH command but does not appear in either the CQL docs or 'help describe'. > I suggest we align the way the 'describe' command works so that it works > consistently regardless of whether it is describing a table, type, function > or any other database object, and also update the CQL and 'help describe' > docs to match. Since 'describe tables' and it's variants has been around the > longest we should probably align other 'describe' commands to 'describe > tables'. > My preliminary analysis has shown at least the following inconsistencies: > - 'desc functions' (with current keyspace), differs from 'desc tables' and > 'desc types'. > - a number of commands are missing from the CQL docs or 'help describe, such > as: desc table ., desc functions (no current keyspace), > desc function , desc type ., etc. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10719) Inconsistencies within CQL 'describe', and CQL docs/'help describe'
[ https://issues.apache.org/jira/browse/CASSANDRA-10719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15013508#comment-15013508 ] Michael Edge commented on CASSANDRA-10719: -- Patch added for all 3 versions. I tested all 3 versions, executing the following test cases. Results were as expected; of course in some cases the test case did not apply to the Cassandra version. For instance, functions and aggregates did not exist in v2.1. h4. Test case bq. Start cqlsh; do not select a keyspace _should return identical results, and match exact ‘help’ entry in cqlsh_ * Help describe * Help desc _should list all objects within all keyspaces_ * Desc tables * Desc functions * Desc aggregates * Desc types _should describe specific object within the named keyspace_ * Desc table . * Desc function . * Desc aggregate . * Desc type . _should describe specific table within the named keyspace_ * Desc . _should fail - 'desc ' is only supported for tables, indexes, views_ * Desc . * Desc . * Desc . bq. Use _should only list objects within that keyspace_ * Desc tables * Desc functions * Desc aggregates * Desc types _should describe specific object within the currently selected keyspace_ * Desc table * Desc function * Desc aggregate * Desc type _should describe specific table within the currently selected keyspace_ * Desc _should fail - 'desc is only supported for tables, indexes, views_ * Desc * Desc * Desc > Inconsistencies within CQL 'describe', and CQL docs/'help describe' > --- > > Key: CASSANDRA-10719 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10719 > Project: Cassandra > Issue Type: Improvement > Components: CQL, Documentation and Website >Reporter: Michael Edge >Assignee: Michael Edge >Priority: Minor > Labels: cqlsh, doc-impacting, docs > Fix For: 3.x > > Attachments: CASSANDRA-2.1-10719-Describe.patch, > CASSANDRA-2.2-10719-Describe.patch, CASSANDRA-3.0-10719-Describe.patch > > > While investigating the issue CASSANDRA-9678 I noticed a number of > inconsistencies in the way 'describe' operates, so I'm opening a new issue to > address these. This issue will also address CASSANDRA-9678. > I'd be happy to work on this. > There are a number of inconsistencies in the way 'describe' operates within > cqlsh, and also in the 'help describe' description within cqlsh compared to > the CQL documentation (at > http://docs.datastax.com/en/cql/3.3/cql/cql_reference/describe_r1.html) > For example, 'desc functions' will list all functions for all keyspaces > regardless of whether there is a current keyspace or not, whereas 'desc > tables' or 'desc types' will list only the tables or types for the current > keyspace. > Some commands exist in cqlsh that are not in the CQL documentation, nor in > the 'help describe' description. For example, 'desc functions' is a valid > CQLSH command but does not appear in either the CQL docs or 'help describe'. > I suggest we align the way the 'describe' command works so that it works > consistently regardless of whether it is describing a table, type, function > or any other database object, and also update the CQL and 'help describe' > docs to match. Since 'describe tables' and it's variants has been around the > longest we should probably align other 'describe' commands to 'describe > tables'. > My preliminary analysis has shown at least the following inconsistencies: > - 'desc functions' (with current keyspace), differs from 'desc tables' and > 'desc types'. > - a number of commands are missing from the CQL docs or 'help describe, such > as: desc table ., desc functions (no current keyspace), > desc function , desc type ., etc. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10719) Inconsistencies within CQL 'describe', and CQL docs/'help describe'
[ https://issues.apache.org/jira/browse/CASSANDRA-10719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Edge updated CASSANDRA-10719: - Attachment: CASSANDRA-2.2-10719-Describe.patch CASSANDRA-2.1-10719-Describe.patch > Inconsistencies within CQL 'describe', and CQL docs/'help describe' > --- > > Key: CASSANDRA-10719 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10719 > Project: Cassandra > Issue Type: Improvement > Components: CQL, Documentation and Website >Reporter: Michael Edge >Assignee: Michael Edge >Priority: Minor > Labels: cqlsh, doc-impacting, docs > Fix For: 3.x > > Attachments: CASSANDRA-2.1-10719-Describe.patch, > CASSANDRA-2.2-10719-Describe.patch, CASSANDRA-3.0-10719-Describe.patch > > > While investigating the issue CASSANDRA-9678 I noticed a number of > inconsistencies in the way 'describe' operates, so I'm opening a new issue to > address these. This issue will also address CASSANDRA-9678. > I'd be happy to work on this. > There are a number of inconsistencies in the way 'describe' operates within > cqlsh, and also in the 'help describe' description within cqlsh compared to > the CQL documentation (at > http://docs.datastax.com/en/cql/3.3/cql/cql_reference/describe_r1.html) > For example, 'desc functions' will list all functions for all keyspaces > regardless of whether there is a current keyspace or not, whereas 'desc > tables' or 'desc types' will list only the tables or types for the current > keyspace. > Some commands exist in cqlsh that are not in the CQL documentation, nor in > the 'help describe' description. For example, 'desc functions' is a valid > CQLSH command but does not appear in either the CQL docs or 'help describe'. > I suggest we align the way the 'describe' command works so that it works > consistently regardless of whether it is describing a table, type, function > or any other database object, and also update the CQL and 'help describe' > docs to match. Since 'describe tables' and it's variants has been around the > longest we should probably align other 'describe' commands to 'describe > tables'. > My preliminary analysis has shown at least the following inconsistencies: > - 'desc functions' (with current keyspace), differs from 'desc tables' and > 'desc types'. > - a number of commands are missing from the CQL docs or 'help describe, such > as: desc table ., desc functions (no current keyspace), > desc function , desc type ., etc. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10719) Inconsistencies within CQL 'describe', and CQL docs/'help describe'
[ https://issues.apache.org/jira/browse/CASSANDRA-10719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15010809#comment-15010809 ] Michael Edge commented on CASSANDRA-10719: -- Sure, no worries. I'll provide a total of 3 patches, for the latest versions of 2.1, 2,2 and 3.0 > Inconsistencies within CQL 'describe', and CQL docs/'help describe' > --- > > Key: CASSANDRA-10719 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10719 > Project: Cassandra > Issue Type: Improvement > Components: CQL, Documentation and Website >Reporter: Michael Edge >Assignee: Michael Edge >Priority: Minor > Labels: cqlsh, docs > Fix For: 3.x > > Attachments: CASSANDRA-3.0-10719-Describe.patch > > > While investigating the issue CASSANDRA-9678 I noticed a number of > inconsistencies in the way 'describe' operates, so I'm opening a new issue to > address these. This issue will also address CASSANDRA-9678. > I'd be happy to work on this. > There are a number of inconsistencies in the way 'describe' operates within > cqlsh, and also in the 'help describe' description within cqlsh compared to > the CQL documentation (at > http://docs.datastax.com/en/cql/3.3/cql/cql_reference/describe_r1.html) > For example, 'desc functions' will list all functions for all keyspaces > regardless of whether there is a current keyspace or not, whereas 'desc > tables' or 'desc types' will list only the tables or types for the current > keyspace. > Some commands exist in cqlsh that are not in the CQL documentation, nor in > the 'help describe' description. For example, 'desc functions' is a valid > CQLSH command but does not appear in either the CQL docs or 'help describe'. > I suggest we align the way the 'describe' command works so that it works > consistently regardless of whether it is describing a table, type, function > or any other database object, and also update the CQL and 'help describe' > docs to match. Since 'describe tables' and it's variants has been around the > longest we should probably align other 'describe' commands to 'describe > tables'. > My preliminary analysis has shown at least the following inconsistencies: > - 'desc functions' (with current keyspace), differs from 'desc tables' and > 'desc types'. > - a number of commands are missing from the CQL docs or 'help describe, such > as: desc table ., desc functions (no current keyspace), > desc function , desc type ., etc. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-10719) Inconsistencies within CQL 'describe', and CQL docs/'help describe'
[ https://issues.apache.org/jira/browse/CASSANDRA-10719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15010223#comment-15010223 ] Michael Edge edited comment on CASSANDRA-10719 at 11/18/15 4:49 AM: Initial patch for cqlsh.ph - this provides consistent behaviour for describe tables, types, functions and aggregates, and also updates the cqlsh 'help describe' documentation. Next step is to update the official Datastax documentation. was (Author: michaeledge): Patch for cqlsh.ph > Inconsistencies within CQL 'describe', and CQL docs/'help describe' > --- > > Key: CASSANDRA-10719 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10719 > Project: Cassandra > Issue Type: Improvement > Components: CQL, Documentation and Website >Reporter: Michael Edge >Assignee: Michael Edge >Priority: Minor > Fix For: 3.x > > Attachments: CASSANDRA-3.0-10719-Describe.patch > > > While investigating the issue CASSANDRA-9678 I noticed a number of > inconsistencies in the way 'describe' operates, so I'm opening a new issue to > address these. This issue will also address CASSANDRA-9678. > I'd be happy to work on this. > There are a number of inconsistencies in the way 'describe' operates within > cqlsh, and also in the 'help describe' description within cqlsh compared to > the CQL documentation (at > http://docs.datastax.com/en/cql/3.3/cql/cql_reference/describe_r1.html) > For example, 'desc functions' will list all functions for all keyspaces > regardless of whether there is a current keyspace or not, whereas 'desc > tables' or 'desc types' will list only the tables or types for the current > keyspace. > Some commands exist in cqlsh that are not in the CQL documentation, nor in > the 'help describe' description. For example, 'desc functions' is a valid > CQLSH command but does not appear in either the CQL docs or 'help describe'. > I suggest we align the way the 'describe' command works so that it works > consistently regardless of whether it is describing a table, type, function > or any other database object, and also update the CQL and 'help describe' > docs to match. Since 'describe tables' and it's variants has been around the > longest we should probably align other 'describe' commands to 'describe > tables'. > My preliminary analysis has shown at least the following inconsistencies: > - 'desc functions' (with current keyspace), differs from 'desc tables' and > 'desc types'. > - a number of commands are missing from the CQL docs or 'help describe, such > as: desc table ., desc functions (no current keyspace), > desc function , desc type ., etc. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10719) Inconsistencies within CQL 'describe', and CQL docs/'help describe'
[ https://issues.apache.org/jira/browse/CASSANDRA-10719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Edge updated CASSANDRA-10719: - Attachment: CASSANDRA-3.0-10719-Describe.patch Patch for cqlsh.ph > Inconsistencies within CQL 'describe', and CQL docs/'help describe' > --- > > Key: CASSANDRA-10719 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10719 > Project: Cassandra > Issue Type: Improvement > Components: CQL, Documentation and Website >Reporter: Michael Edge >Assignee: Michael Edge >Priority: Minor > Fix For: 3.x > > Attachments: CASSANDRA-3.0-10719-Describe.patch > > > While investigating the issue CASSANDRA-9678 I noticed a number of > inconsistencies in the way 'describe' operates, so I'm opening a new issue to > address these. This issue will also address CASSANDRA-9678. > I'd be happy to work on this. > There are a number of inconsistencies in the way 'describe' operates within > cqlsh, and also in the 'help describe' description within cqlsh compared to > the CQL documentation (at > http://docs.datastax.com/en/cql/3.3/cql/cql_reference/describe_r1.html) > For example, 'desc functions' will list all functions for all keyspaces > regardless of whether there is a current keyspace or not, whereas 'desc > tables' or 'desc types' will list only the tables or types for the current > keyspace. > Some commands exist in cqlsh that are not in the CQL documentation, nor in > the 'help describe' description. For example, 'desc functions' is a valid > CQLSH command but does not appear in either the CQL docs or 'help describe'. > I suggest we align the way the 'describe' command works so that it works > consistently regardless of whether it is describing a table, type, function > or any other database object, and also update the CQL and 'help describe' > docs to match. Since 'describe tables' and it's variants has been around the > longest we should probably align other 'describe' commands to 'describe > tables'. > My preliminary analysis has shown at least the following inconsistencies: > - 'desc functions' (with current keyspace), differs from 'desc tables' and > 'desc types'. > - a number of commands are missing from the CQL docs or 'help describe, such > as: desc table ., desc functions (no current keyspace), > desc function , desc type ., etc. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CASSANDRA-9678) help describe is missing the documentation for UDTs
[ https://issues.apache.org/jira/browse/CASSANDRA-9678?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Edge reassigned CASSANDRA-9678: --- Assignee: Michael Edge > help describe is missing the documentation for UDTs > --- > > Key: CASSANDRA-9678 > URL: https://issues.apache.org/jira/browse/CASSANDRA-9678 > Project: Cassandra > Issue Type: Improvement >Reporter: Peter Halliday >Assignee: Michael Edge >Priority: Minor > Labels: cqlsh > Fix For: 2.1.x > > > On 2.1 when you type help describe, the documentation for describe types is > missing. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10719) Inconsistencies within CQL 'describe', and CQL docs/'help describe'
[ https://issues.apache.org/jira/browse/CASSANDRA-10719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Edge updated CASSANDRA-10719: - Description: While investigating the issue CASSANDRA-9678 I noticed a number of inconsistencies in the way 'describe' operates, so I'm opening a new issue to address these. This issue will also address CASSANDRA-9678. I'd be happy to work on this. There are a number of inconsistencies in the way 'describe' operates within cqlsh, and also in the 'help describe' description within cqlsh compared to the CQL documentation (at http://docs.datastax.com/en/cql/3.3/cql/cql_reference/describe_r1.html) For example, 'desc functions' will list all functions for all keyspaces regardless of whether there is a current keyspace or not, whereas 'desc tables' or 'desc types' will list only the tables or types for the current keyspace. Some commands exist in cqlsh that are not in the CQL documentation, nor in the 'help describe' description. For example, 'desc functions' is a valid CQLSH command but does not appear in either the CQL docs or 'help describe'. I suggest we align the way the 'describe' command works so that it works consistently regardless of whether it is describing a table, type, function or any other database object, and also update the CQL and 'help describe' docs to match. Since 'describe tables' and it's variants has been around the longest we should probably align other 'describe' commands to 'describe tables'. My preliminary analysis has shown at least the following inconsistencies: - 'desc functions' (with current keyspace), differs from 'desc tables' and 'desc types'. - a number of commands are missing from the CQL docs or 'help describe, such as: desc table ., desc functions (no current keyspace), desc function , desc type ., etc. was: While investigating the issue CASSANDRA-9678 I noticed a number of inconsistencies in the way 'describe' operates, so I'm opening a new issue to address these. This issue will also address Cassandra-9678. I'd be happy to work on this. There are a number of inconsistencies in the way 'describe' operates within cqlsh, and also in the 'help describe' description within cqlsh compared to the CQL documentation (at http://docs.datastax.com/en/cql/3.3/cql/cql_reference/describe_r1.html) For example, 'desc functions' will list all functions for all keyspaces regardless of whether there is a current keyspace or not, whereas 'desc tables' or 'desc types' will list only the tables or types for the current keyspace. Some commands exist in cqlsh that are not in the CQL documentation, nor in the 'help describe' description. For example, 'desc functions' is a valid CQLSH command but does not appear in either the CQL docs or 'help describe'. I suggest we align the way the 'describe' command works so that it works consistently regardless of whether it is describing a table, type, function or any other database object, and also update the CQL and 'help describe' docs to match. Since 'describe tables' and it's variants has been around the longest we should probably align other 'describe' commands to 'describe tables'. My preliminary analysis has shown at least the following inconsistencies: - 'desc functions' (with current keyspace), differs from 'desc tables' and 'desc types'. - a number of commands are missing from the CQL docs or 'help describe, such as: desc table ., desc functions (no current keyspace), desc function , desc type ., etc. > Inconsistencies within CQL 'describe', and CQL docs/'help describe' > --- > > Key: CASSANDRA-10719 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10719 > Project: Cassandra > Issue Type: Improvement > Components: CQL, Documentation and Website >Reporter: Michael Edge >Priority: Minor > Fix For: 3.x > > > While investigating the issue CASSANDRA-9678 I noticed a number of > inconsistencies in the way 'describe' operates, so I'm opening a new issue to > address these. This issue will also address CASSANDRA-9678. > I'd be happy to work on this. > There are a number of inconsistencies in the way 'describe' operates within > cqlsh, and also in the 'help describe' description within cqlsh compared to > the CQL documentation (at > http://docs.datastax.com/en/cql/3.3/cql/cql_reference/describe_r1.html) > For example, 'desc functions' will list all functions for all keyspaces > regardless of whether there is a current keyspace or not, whereas 'desc > tables' or 'desc types' will list only the tables or types for the current > keyspace. > Some commands exist in cqlsh that are not in the CQL documentation, nor in > the 'help describe' description. For example, 'desc functions' is a valid > CQLSH command but does not appear
[jira] [Updated] (CASSANDRA-10719) Inconsistencies within CQL 'describe', and CQL docs/'help describe'
[ https://issues.apache.org/jira/browse/CASSANDRA-10719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Edge updated CASSANDRA-10719: - Description: While investigating the issue CASSANDRA-9678 I noticed a number of inconsistencies in the way 'describe' operates, so I'm opening a new issue to address these. This issue will also address Cassandra-9678. I'd be happy to work on this. There are a number of inconsistencies in the way 'describe' operates within cqlsh, and also in the 'help describe' description within cqlsh compared to the CQL documentation (at http://docs.datastax.com/en/cql/3.3/cql/cql_reference/describe_r1.html) For example, 'desc functions' will list all functions for all keyspaces regardless of whether there is a current keyspace or not, whereas 'desc tables' or 'desc types' will list only the tables or types for the current keyspace. Some commands exist in cqlsh that are not in the CQL documentation, nor in the 'help describe' description. For example, 'desc functions' is a valid CQLSH command but does not appear in either the CQL docs or 'help describe'. I suggest we align the way the 'describe' command works so that it works consistently regardless of whether it is describing a table, type, function or any other database object, and also update the CQL and 'help describe' docs to match. Since 'describe tables' and it's variants has been around the longest we should probably align other 'describe' commands to 'describe tables'. My preliminary analysis has shown at least the following inconsistencies: - 'desc functions' (with current keyspace), differs from 'desc tables' and 'desc types'. - a number of commands are missing from the CQL docs or 'help describe, such as: desc table ., desc functions (no current keyspace), desc function , desc type ., etc. was: While investigating the issue Cassandra-9678 I noticed a number of inconsistencies in the way 'describe' operates, so I'm opening a new issue to address these. This issue will also address Cassandra-9678. I'd be happy to work on this. There are a number of inconsistencies in the way 'describe' operates within cqlsh, and also in the 'help describe' description within cqlsh compared to the CQL documentation (at http://docs.datastax.com/en/cql/3.3/cql/cql_reference/describe_r1.html) For example, 'desc functions' will list all functions for all keyspaces regardless of whether there is a current keyspace or not, whereas 'desc tables' or 'desc types' will list only the tables or types for the current keyspace. Some commands exist in cqlsh that are not in the CQL documentation, nor in the 'help describe' description. For example, 'desc functions' is a valid CQLSH command but does not appear in either the CQL docs or 'help describe'. I suggest we align the way the 'describe' command works so that it works consistently regardless of whether it is describing a table, type, function or any other database object, and also update the CQL and 'help describe' docs to match. Since 'describe tables' and it's variants has been around the longest we should probably align other 'describe' commands to 'describe tables'. My preliminary analysis has shown at least the following inconsistencies: - 'desc functions' (with current keyspace), differs from 'desc tables' and 'desc types'. - a number of commands are missing from the CQL docs or 'help describe, such as: desc table ., desc functions (no current keyspace), desc function , desc type ., etc. > Inconsistencies within CQL 'describe', and CQL docs/'help describe' > --- > > Key: CASSANDRA-10719 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10719 > Project: Cassandra > Issue Type: Improvement > Components: CQL, Documentation and Website >Reporter: Michael Edge >Priority: Minor > Fix For: 3.x > > > While investigating the issue CASSANDRA-9678 I noticed a number of > inconsistencies in the way 'describe' operates, so I'm opening a new issue to > address these. This issue will also address Cassandra-9678. > I'd be happy to work on this. > There are a number of inconsistencies in the way 'describe' operates within > cqlsh, and also in the 'help describe' description within cqlsh compared to > the CQL documentation (at > http://docs.datastax.com/en/cql/3.3/cql/cql_reference/describe_r1.html) > For example, 'desc functions' will list all functions for all keyspaces > regardless of whether there is a current keyspace or not, whereas 'desc > tables' or 'desc types' will list only the tables or types for the current > keyspace. > Some commands exist in cqlsh that are not in the CQL documentation, nor in > the 'help describe' description. For example, 'desc functions' is a valid > CQLSH command but does not appear
[jira] [Commented] (CASSANDRA-9678) help describe is missing the documentation for UDTs
[ https://issues.apache.org/jira/browse/CASSANDRA-9678?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15008651#comment-15008651 ] Michael Edge commented on CASSANDRA-9678: - While investigating this issue I noticed quite a few other inconsistencies between the way 'describe' operates and what is stated in the CQL docs and 'help describe', so I raised another issue (CASSANDRA-10719) to encompass all of these. I'd be happy to fix this issue, CASSANDRA-9678, along with the wider issues listed in CASSANDRA-10719. > help describe is missing the documentation for UDTs > --- > > Key: CASSANDRA-9678 > URL: https://issues.apache.org/jira/browse/CASSANDRA-9678 > Project: Cassandra > Issue Type: Improvement >Reporter: Peter Halliday >Priority: Minor > Labels: cqlsh > Fix For: 2.1.x > > > On 2.1 when you type help describe, the documentation for describe types is > missing. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CASSANDRA-10719) Inconsistencies within CQL 'describe', and CQL docs/'help describe'
Michael Edge created CASSANDRA-10719: Summary: Inconsistencies within CQL 'describe', and CQL docs/'help describe' Key: CASSANDRA-10719 URL: https://issues.apache.org/jira/browse/CASSANDRA-10719 Project: Cassandra Issue Type: Improvement Components: CQL, Documentation and Website Reporter: Michael Edge Priority: Minor Fix For: 3.x While investigating the issue Cassandra-9678 I noticed a number of inconsistencies in the way 'describe' operates, so I'm opening a new issue to address these. This issue will also address Cassandra-9678. I'd be happy to work on this. There are a number of inconsistencies in the way 'describe' operates within cqlsh, and also in the 'help describe' description within cqlsh compared to the CQL documentation (at http://docs.datastax.com/en/cql/3.3/cql/cql_reference/describe_r1.html) For example, 'desc functions' will list all functions for all keyspaces regardless of whether there is a current keyspace or not, whereas 'desc tables' or 'desc types' will list only the tables or types for the current keyspace. Some commands exist in cqlsh that are not in the CQL documentation, nor in the 'help describe' description. For example, 'desc functions' is a valid CQLSH command but does not appear in either the CQL docs or 'help describe'. I suggest we align the way the 'describe' command works so that it works consistently regardless of whether it is describing a table, type, function or any other database object, and also update the CQL and 'help describe' docs to match. Since 'describe tables' and it's variants has been around the longest we should probably align other 'describe' commands to 'describe tables'. My preliminary analysis has shown at least the following inconsistencies: - 'desc functions' (with current keyspace), differs from 'desc tables' and 'desc types'. - a number of commands are missing from the CQL docs or 'help describe, such as: desc table ., desc functions (no current keyspace), desc function , desc type ., etc. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10464) "nodetool compactionhistory" output should be sorted on compacted_at column and the timestamp shown in human readable format
[ https://issues.apache.org/jira/browse/CASSANDRA-10464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15008177#comment-15008177 ] Michael Edge commented on CASSANDRA-10464: -- Patch attached. I made the changes in CompactionHistory.java to ensure only NodeTool is impacted. It would have been easier to change CompactionHistoryTabularData.java, since this is where the data retrieved from the system table is formatted, but I was unsure whether this would impact any other consumers or JMX users/apps. My first Cassandra patch - please be gentle... > "nodetool compactionhistory" output should be sorted on compacted_at column > and the timestamp shown in human readable format > > > Key: CASSANDRA-10464 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10464 > Project: Cassandra > Issue Type: Improvement >Reporter: Wei Deng >Priority: Minor > Fix For: 3.x > > Attachments: CASSANDRA-10464-CompactionHistory.patch > > > "nodetool compactionhistory" (introduced in CASSANDRA-5078) is a useful tool > for Cassandra DBAs. However, the current output limits its usefulness without > some additional parsing. > We should improve it in the following two areas: > 1. The output should be sorted on the compacted_at column, so that the most > recently finished compaction will show up last (which is what the DBAs would > expect); > 2. The compacted_at column should be printed in human-readable timestamp. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10464) "nodetool compactionhistory" output should be sorted on compacted_at column and the timestamp shown in human readable format
[ https://issues.apache.org/jira/browse/CASSANDRA-10464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Edge updated CASSANDRA-10464: - Attachment: CASSANDRA-10464-CompactionHistory.patch > "nodetool compactionhistory" output should be sorted on compacted_at column > and the timestamp shown in human readable format > > > Key: CASSANDRA-10464 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10464 > Project: Cassandra > Issue Type: Improvement >Reporter: Wei Deng >Priority: Minor > Fix For: 3.x > > Attachments: CASSANDRA-10464-CompactionHistory.patch > > > "nodetool compactionhistory" (introduced in CASSANDRA-5078) is a useful tool > for Cassandra DBAs. However, the current output limits its usefulness without > some additional parsing. > We should improve it in the following two areas: > 1. The output should be sorted on the compacted_at column, so that the most > recently finished compaction will show up last (which is what the DBAs would > expect); > 2. The compacted_at column should be printed in human-readable timestamp. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
