lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jason Gerlowski (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (SOLR-11206) Migrate logic from bin/solr scripts to SolrCLI
Date Tue, 08 Aug 2017 03:56:00 GMT

    [ https://issues.apache.org/jira/browse/SOLR-11206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16117815#comment-16117815
] 

Jason Gerlowski edited comment on SOLR-11206 at 8/8/17 3:55 AM:
----------------------------------------------------------------

*Questions/Concerns/Thoughts*

Most of these are just some notes I wanted to jot down for my own benefit.  Though they may
provide helpful for others to catch my mistakes/misconceptions...

* AFAIK, there are no tests for the bin/solr scripts themselves, are there?  I'm concerned
about inadvertently introducing bugs that will cause user issues down the road.  Looks like
a Catch-22 of sorts: moving the logic to Java will allow it to be better tested, but it's
difficult to refactor with confidence because of the current test situation.  With that in
mind, one of my first steps here might be to put together a script which exercises the {{bin/solr}}
commands in many ways.  It's obviously not feasible to capture all (or even most) cases, but
a gap/hole-ridden benchmark is better than none at all.
* A "benchmark" script like the one suggested above could be used to diff the output before
and after this refactor, to ensure that the output isn't changing in any ways we don't expect/anticipate/want.
 Do the backcompat guarantees made elsewhere in Solr extend to the output of these scripts
as well?  Or is there not a rigid expectation around the Solr control scripts?
* I suspect I might run into some discrepancies in behavior between the two bin/solr implementations.
 I suppose these will just have to be handled on a case by case basis (as far as determining
which behavior should be taken forward.)


was (Author: gerlowskija):
*Questions/Concerns/Thoughts*

Most of these are just some notes I wanted to jot down for my own benefit.  Though they may
provide helpful for others to catch my mistakes/misconceptions...

* AFAIK, there are no tests for the bin/solr scripts themselves, are there?  I'm concerned
about inadvertently introducing bugs that will cause users issues down the road.  With that
in mind, one of my first steps here might be to put together a script which exercises the
{{bin/solr}} commands in many ways.  It's obviously not feasible to capture all cases, but
a gap/hole-ridden benchmark is better than none at all.
* A "benchmark" script like the one suggested above could be used to diff the output before
and after this refactor, to ensure that the output isn't changing in any ways we don't expect/anticipate/want.
 Do the backcompat guarantees made elsewhere in Solr extend to the output of these scripts
as well?  Or is there not a rigid expectation around that?
* I suspect I might run into some discrepancies in behavior between the two bin/solr implementations.
 I suppose these will just have to be handled on a case by case basis (as far as determining
which behavior should be taken forward.)

> Migrate logic from bin/solr scripts to SolrCLI
> ----------------------------------------------
>
>                 Key: SOLR-11206
>                 URL: https://issues.apache.org/jira/browse/SOLR-11206
>             Project: Solr
>          Issue Type: Improvement
>      Security Level: Public(Default Security Level. Issues are Public) 
>          Components: scripts and tools
>            Reporter: Jason Gerlowski
>             Fix For: master (8.0)
>
>
> The {{bin/solr}} and {{bin/solr.cmd}} scripts have taken on a lot of logic that would
be easier to maintain if it was instead written in Java code, for a handful of reasons
> * Any logic in the control scripts is duplicated in two places by definition.
> * Increasing test coverage of this logic would be much easier if it was written in Java.
> * Few developers are conversant in both bash and Windows-shell, making editing difficult.
> Some sections in these scripts make good candidates for migration to Java.  This issue
should examine any of these that are brought up.  However the biggest and most obvious candidate
for migration is the argument parsing, validation, usage/help text, etc. for the commands
that don't directly start/stop Solr processes (i.e. the "create", "delete", "zk", "auth",
"assert" commands).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message