[
https://issues.apache.org/jira/browse/SOLR-6115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shalin Shekhar Mangar updated SOLR-6115:
Attachment: SOLR-6115.patch
# Refactor Overseer, OverseerCollectionProcessor and CollectionHandler to use
enums instead of strings
# Created a new enum called OverseerAction which has actions specific to
Overseer. I didn't want to expose them in the CollectionAction enum which is
public and part of SolrJ.
# Found and changed all references in code and tests.
# Renamed createcollection to create, removecollection to delete and
removeshard to deleteshard to match corresponding CollectionAction enums.
This has the side effect that the keys for these stats in the overseerstatus
API are also renamed but I think that should be okay. I've documented this
compat break in the change log. We continue to handle existing items in the
overseer queue to preserve back-compat during rolling upgrades.
Cleanup enum/string action types in Overseer, OverseerCollectionProcessor and
CollectionHandler
---
Key: SOLR-6115
URL: https://issues.apache.org/jira/browse/SOLR-6115
Project: Solr
Issue Type: Task
Components: SolrCloud
Reporter: Shalin Shekhar Mangar
Priority: Minor
Fix For: 4.9, 5.0
Attachments: SOLR-6115.patch
The enum/string handling for actions in Overseer and OCP is a mess. We should
fix it.
From:
https://issues.apache.org/jira/browse/SOLR-5466?focusedCommentId=13918059page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13918059
{quote}
I started to untangle the fact that we have all the strings in
OverseerCollectionProcessor, but also have a nice CollectionAction enum. And
the commands are intermingled with parameters, it all seems rather confusing.
Does it make sense to use the enum rather than the strings? Or somehow
associate the two? Probably something for another JIRA though...
{quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
