>> collection.configName
> Where is this used as a system property override? I looked and don't see
> it.
Yea, this should not have been in the list. Removed
> "enabled" vs "disabled": can we standardize on "enabled"?
That would have been nice. I think typically .enabled is used when default is
The categories and your comments make sense to me.
I looked across some of the individual proposals:
> collection.configName
Where is this used as a system property override? I looked and don't see
it.
"enabled" vs "disabled": can we standardize on "enabled"?
> managed.schema.mutable
In this
I like the simplicity of lowercasing and changing underscore for dot, so if we
can avoid camelCase that would be best.
I started a WIKI page for easier collaboration on this topic:
https://cwiki.apache.org/confluence/display/SOLR/System+property+naming+structure
There I enumerated each source
On Tue, Jan 9, 2024 at 9:49 AM Jan Høydahl wrote:
> Hi,
>
> > Using this one as an example; what would you propose?:
> > * solr.shardSplit.checkDiskSpace.enabled
>
> The "solr.shardSplit.checkDiskSpace.enabled" prop is one of the better.
> But say we standardized the first component layer to be o
Hi,
> Using this one as an example; what would you propose?:
> * solr.shardSplit.checkDiskSpace.enabled
The "solr.shardSplit.checkDiskSpace.enabled" prop is one of the better. But say
we standardized the first component layer to be one of "query", "index",
"collection", "schema", "cluster", "no
Thanks for working on this and raising the topic of config naming
standardization!
Using this one as an example; what would you propose?:
* solr.shardSplit.checkDiskSpace.enabled
Thankfully, it already uses two best practices (A) starting with "solr."
and (B) a module/category "shardSplit". What
