[
https://issues.apache.org/jira/browse/CASSANDRA-18661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17798930#comment-17798930
]
Claude Warren commented on CASSANDRA-18661:
-------------------------------------------
I spent some time this morning looking at this. I can not find a way to
process options without a leading dash. There are comments in the mailing list
about how options require such prefixes to distinguish them from arguments to
the options.
I looked at adding dashes to the existing sub-options but this all gets very
complicated very quickly. For example there is not a way to support 'n<',
'n>', and 'n=' in the same set of options. if we preprocess the line and add
'-D' (or something similar) to the front so we have something like '-Dn<5' that
will probably work. However we are then replacing the custom code with new
custom code to make it fit the CLI code.
The other option is to take the arguments from the sub-options and process them
as we do now. In this case we are only using the CLI to process the
sub-options.
We could build a system that takes the arguments for the sub-options, splits
the sub options so that items like "n<5" become \{"n", "<5"} and then process
the result with an iterator where we lookup the argument in a table and pass
the iterator to a method that then handles the configuration for that argument
before returning and allowing the next argument to be pulled from the iterator.
In this way we can process arguments that take arguments (e.g. err<0.5 or
n>6). But again we are back to lots of custom processing. However we can
switch to using Predicate<Iterator<String>> and perhaps simplify some of the
system while making it easier to extend with new options later.
I am on the fence with this. I am willing to take a look to see if we can
simplify and/or update, but I don't know if there is enough support to change
this when we will still have a fair amount of custom code. I'll continue to
explore for the rest of today and perhaps tomorrow. But I would appreciate any
guidance with respect to whether or not this would be accepted if the change to
CLI provides minimal change to the processing.
> Update cassandra-stress to use Apache Commons CLI
> -------------------------------------------------
>
> Key: CASSANDRA-18661
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18661
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/stress
> Reporter: Brad Schoening
> Assignee: Claude Warren
> Priority: Normal
> Labels: lhf
>
> The Apache Commons CLI library provides an API for parsing command line
> options with the package org.apache.commons.cli and this is already used by a
> dozen of existing Cassandra utilities including:
> {quote}SSTableMetadataViewer, StandaloneScrubber, StandaloneSplitter,
> SSTableExport, BulkLoader, and others.
> {quote}
> However, cassandra-stress is an outlier which uses its own custom classes to
> parse command line options with classes such as OptionsSimple. In addition,
> the options syntax for username, password, and others are not aligned with
> the format used by CQLSH.
> Currently, there are > 5K lines of code in 'settings' which appears to just
> process command line args.
> This suggestion is to:
>
> a) Upgrade cassandra-stress to use Apache Commons CLI (no new dependencies
> are required as this library is already used by the project)
>
> b) Align the cassandra-stress CLI options with those in CQLSH,
>
> {quote}For example, using the new syntax like CQLSH:
> {quote}
>
> cassandra-stress -username foo -password bar
> {quote}and replacing the old syntax:
> {quote}
> cassandra-stress -mode username=foo and password=bar
>
> This will simplify and unify the code base, eliminate code and reduce the
> confusion between similar named classes such as
> org.apache.cassandra.stress.settings.\{Option, OptionsMulti, OptionsSimple}
> and org.apache.commons.cli.{Option, OptionGroup, Options)
>
> Note: documentation will need to be updated as well
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
