[
https://issues.apache.org/jira/browse/SOLR-5756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14653993#comment-14653993
]
Scott Blum commented on SOLR-5756:
----------------------------------
1) I don't understand. `if (children == null || children.isEmpty()) {` isn't
that the null check?
2) constructState() actually updates the field as a side effect, and it's the
ONLY place I'm ever writing to the field. I put it inside the method because I
was just having to do clusterState = constructState() at every call site. I
can outline it if you think it's unclear, or I can rename the method. I was
just sticking with the old name, but maybe that doesn't make sense now.
"updateView" maybe?
3) I actually intentionally left the live node and alias code alone, even
though I have the strong urge to refactor it to match the new patterns I'm
creating, since it wasn't directly related to the change. That said, I would
be totally happy to create a LiveNodeWatcher along the lines of StateWatcher
(which would enable shared code) if you think I should go ahead with that!
4) Awesome, I was hoping for some guidance on this. For "shared" clusterstate,
should I use "shared" or "legacyFormat"?
As far as testing goes, I'll hit you up on IRC for some pointers on writing
this. Ideally, if you could point me at an existing test I could start from?
> A utility API to move collections from internal to external
> -----------------------------------------------------------
>
> Key: SOLR-5756
> URL: https://issues.apache.org/jira/browse/SOLR-5756
> Project: Solr
> Issue Type: Bug
> Reporter: Noble Paul
> Assignee: Shalin Shekhar Mangar
> Attachments: SOLR-5756-trunk.patch, SOLR-5756-vs-5.2.1.patch
>
>
> SOLR-5473 allows creation of collection with state stored outside of
> clusterstate.json. We would need an API to move existing 'internal'
> collections outside
--
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
