[
https://issues.apache.org/jira/browse/SOLR-9569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15541361#comment-15541361
]
Noble Paul commented on SOLR-9569:
----------------------------------
bq.Do we continue to use properties files, with core.properties being a prime
example?
.properties files are good for editing. In a solrcloud world we don't expect
any of the conf files to be hand edited by users.
bq.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
There is an impedance mismatch between XML & JSON. It does not mean that XML is
better than JSON. It just means they are different and we have been using one
over another. As our components get used to the new format, this will be OK
bq.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.
I'm unable to understand this. care to elaborate?
bq.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
This is a missing feature. To be implemented . When you view/save it the
templates must show up as specified and not the substituted values
bq.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
it is indeed supposed to be better than XML in that aspect. You could look at
the security,json for a taste of things to come. The format of the config is
delegated to the component itself. So, the component can actually
validate/read/persist its configuration
bq.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.
round-tripping should be an objective. I don't see any reason why can't achieve
it
> 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]
