[
https://issues.apache.org/jira/browse/SOLR-5473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13982173#comment-13982173
]
Mark Miller commented on SOLR-5473:
-----------------------------------
Thanks for chiming in.
bq. Do we intend to support both formats or do we intend to just migrate to the
split approach?
We intend to migrate - I think supporting both would be a terrible long term
burden. The way the API's are currently designed, this was obviously not taken
into account. It's designed as if both things are first class.
bq. Are there any other things design / architecture wise that are
controversial?
I think that mostly captures it.
bq. This seems like the biggest area of contention right now.
Yup - this is what makes me insist on backing this out for now, rather than
pushing forward.
bq. The main issue is that the API changes still give the impression of two
state tracking formats, whereas we really only want one format.
That is part of it, but I also think the API's are somewhat poorly designed
from an overall architecture point - it feels to me like shortcuts around more
difficult issues to make nice and I think that is the wrong approach. I've got
a variety of other issues, for instance, I think it's an abomination the way
ZkStateReader has been worked into ClusterState, and I think the documentation
is much too weak in areas that would call for it.
bq. The common ground here is that there should be no mention of "external" in
any public method or state format for that matter, right?
Right. We should have the new format, and the old one is around for back
compat. There is no reason to name things in this case. We are pushing forward
the architecture, not adding a feature.
bq. In other words, we're changing the internals of where state is kept, so why
does that have to impact the public API? I
That was also my thought - and I think it probably gets sticky due to
supporting both formats per collection, but I think we have to tackle those
hard problems.
bq. It seems to me that we need to be more diligent about API impacts of this
change and focus on not breaking the public view of cluster state as much as
possible.
I agree - though it's too early to really hold to that. I do think we should be
better about labeling unstable API's though. We can't lock our selves in to
early though - it would block a lot of progress and we tend to be loose with
Solr java API's - it's standard that you may have to recompile. We should be
sensible though. However, I think a user would have a very terrible time
migrating to the new API's. I'm hoping we can back them out before it becomes
too much harder to do so.
bq. To recap, I see a lot of common ground here and to move forward, we need to
move this out to a branch and off trunk where we'll focus on cleaning up the
API impacts of this work, support only the split format going forward (with a
migration plan for existing installations).
+1
Thanks [~thelabdude], I am on the same page as you with all of that.
> Make one state.json per collection
> ----------------------------------
>
> Key: SOLR-5473
> URL: https://issues.apache.org/jira/browse/SOLR-5473
> Project: Solr
> Issue Type: Sub-task
> Components: SolrCloud
> Reporter: Noble Paul
> Assignee: Noble Paul
> Fix For: 5.0
>
> Attachments: SOLR-5473-74.patch, SOLR-5473-74.patch,
> SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch,
> SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch,
> SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch,
> SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch,
> SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch,
> SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch,
> SOLR-5473-74.patch, SOLR-5473-74.patch, SOLR-5473-74.patch,
> SOLR-5473-74.patch, SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch,
> SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch,
> SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch,
> SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch,
> SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, ec2-23-20-119-52_solr.log,
> ec2-50-16-38-73_solr.log
>
>
> As defined in the parent issue, store the states of each collection under
> /collections/collectionname/state.json node
--
This message was sent by Atlassian JIRA
(v6.2#6252)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
