[
https://issues.apache.org/jira/browse/SOLR-9569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15542029#comment-15542029
]
Alexandre Rafalovitch commented on SOLR-9569:
---------------------------------------------
bq. 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
XML is richer and is legacy. So, the question is how we are going to deal with
that. I am not sure I understood the answer. Perhaps that is something that is
obvious to those deep into it, but I feel it is still a valid question given
the complexity of code I am seeing already.
bq. I'm unable to understand this (...the default values become explicit
values...). care to elaborate?
Right now, the /config against the core with default configuration returns:
_"commitWithin":{"softCommit":true}_, the setting that is nowhere in the
solrconfig for the core. So, if that round-trips back to whatever format, we
suddenly have additional setting in the file, making it bloated. Same with JMX,
the /config inserts 3 null-value properties.
bq. 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.
I could not find a representative security.json in the codebase. Could you
point out the one you mean. I could also not see any evidence of round-tripping
in the code, just reading from the json file. The complexities I am trying to
discuss are of round-tripping as well as dealing with multiple-sources in a
meaningful way.
bq. round-tripping should be an objective. I don't see any reason why can't
achieve it
Just because something is achievable theoretically, does not mean we started on
the road in the right direction. I am not saying we have, but I cannot find the
discussion explaining how the current _effective_ direction is supposed to -
eventually - take care of the issues I raised.
> 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]
