[
https://issues.apache.org/jira/browse/SOLR-9569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15540750#comment-15540750
]
Alexandre Rafalovitch commented on SOLR-9569:
---------------------------------------------
I am comparing solrconfig.xml and the output of the /config command and I see
the following challenges in going forward to something that can round-trip via
JSON:
* XML entities have attributes as well as child entries, JSON has only child
entries (nested objects and properties), so the /config output combines the
attributes and nested properties together. Given that both attributes and
nested entities may be arbitrary, this mapping is a one-way street. The
question is whether we loose anything in this simplification
* With the current implementation, the default values become explicit values
(e.g. commitWithin/softCommit), which pollutes the human-comprehension
(specifically, the minimal config file showing only deviation from defaults).
It is wonderful to be able to see the defaults, but that should be an optional
extra, not a forced representation.
* The variable substitutions are lost/materialized (e.g.
$\{solr.autoCommit.maxTime:15000\}), which is ignorable for one-way trip, but
not for round-trip as users may want to change those variables later from the
command line or in core.properties
* There are still some significant output weirdness with null values (e.g. for
JMX), empty keys (e.g. inside updateRequestProcessorChain), missing entries
(perSegFilter), and loosing/simplifying-away component names (e.g.
highlighting).
* I believe solrconfig.xml is supposed to be extendable to plugins that can
inject/read their own attributes/entities. I suspect all of those are ignored
when /config is called
* The code between the config reading class, config output and overlay
setters/getters feels heavily duplicate yet inconsistent and prone to getting
out-of-sync on a slightest change.
This was not the case for the schema, as it was much more controlled. But
solrconfig.xml is somewhat more complex structure and it feels that the current
most-direct approach may not take us very far, and certainly not to the
round-trip end-goal.
I don't have an answer to the above. Still, I have a vague feeling that perhaps
some sort of meta-representation of the solrconfig structure taking advantage
of the latest Java 8 features (method pointers, lambdas, etc) would give us a
more consistent path forward.
> Moving to a unified solrconfig experience
> -----------------------------------------
>
> Key: SOLR-9569
> URL: https://issues.apache.org/jira/browse/SOLR-9569
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Noble Paul
> Assignee: Noble Paul
>
> * Any config API call will result in a collection reload. We should ensure
> that only the relevant component is reloaded. This will work only for
> components specified in the configoverlay.json
> * Move most commonly used paths to ImplicitPlugins
> * move their request parameters to params.json
> * Enhance the config API to expand show the params used for each
> requesthandler inline
> Today we use the solrconfig.xml as a place to document things. As we move
> more stuff off of solrconfig.xml let's point it to a ref guide page to
> discuss about all the requesthandlers available by default and their
> configuration
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
