[
https://issues.apache.org/jira/browse/SOLR-14680?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17178292#comment-17178292
]
Andrzej Bialecki commented on SOLR-14680:
-----------------------------------------
{quote}So, you build everything together and and commit everything altogether?
{quote}
Not everything, but at least *some* working parts, even one.
BTW. this has been the way we've been introducing new APIs so far, and there's
a very good reason for this: there's no proof (as in working code) that the new
APIs are correct or sufficient for their purpose. I mentioned that they are
similar (but different) from the APIs we're considering in PR 1684, but IMHO
your version doesn't sufficiently model even the current data, such as eg.
arbitrary collection or shard properties, or shard and replica state. There's
no explanation why you omitted this data because there's neither a design doc
nor any working code.
Poor formatting and failing precommit are easily rectified, but the above
issues require a much better explanation that what we have now.
{quote}This is how I wish to go about this
* Build the APIs, we should keep it to just the interfaces so that people get
to comment on what it is
* We should build one implementation of these interfaces{quote}
And that's the phase where I think it would be justified to commit it. Show me
a few existing components that can use this new API to prove that it's accurate
and sufficient for the purpose.
{quote} * We should slowly refactor our code to use these APIs{quote}
I agree - but it's a huge task and I'm not sure there's enough manpower
dedicated to fully do this refactoring both in 9.0 and in 8x. That's why I
think this should go first to 9.0, which is the right place for the new APIs to
be "baked in", and then possibly be back-ported to 8x after initial bugs and
issues are resolved and if there's enough manpower to actually complete this
refactoring there (and whether it brings such benefits to 8x that it's worth
the effort).
As for the back-compat - sure, we can preserve the back-compat in 8x but at
what cost? Just re-packaging {{ClusterState}} with all its components will be
messy, and that's the API that is exposed to clients.
{quote}bq. Once we are reasonably happy about the APIs
{quote}
Exactly - that's why the place for these new APIs is in 9.0 and not in 8x.
{quote}There is not point in introducing fresh new APIs in 9.0.
{quote}
Excuse me? that's the whole point of 9.0.
> Provide simple interfaces to our concrete SolrCloud classes
> -----------------------------------------------------------
>
> Key: SOLR-14680
> URL: https://issues.apache.org/jira/browse/SOLR-14680
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Noble Paul
> Assignee: Noble Paul
> Priority: Minor
> Time Spent: 10.5h
> Remaining Estimate: 0h
>
> All our current implementations of SolrCloud such as
> # ClusterState
> # DocCollection
> # Slice
> # Replica
> etc are concrete classes. Providing alternate implementations or wrappers is
> extremely difficult.
> SOLR-14613 is attempting to create such interfaces to make their sdk simpler
> The objective is not to have a comprehensive set of methods in these
> interfaces. We will start out with a subset of required interfaces. We
> guarantee is that signatures of methods in these interfaces will not be
> deleted/changed . But we may add more methods as and when it suits us
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
