This effort was discussed in today's Community meeting and is now SIP-21
https://cwiki.apache.org/confluence/display/SOLR/SIP-21%3A+Standardize+system+property+naming
Please have a look and help out carving out what categories to place properties
in to drive the effort closer to implementation, which will be a series of PRs
renaming groups of properties).
Jan
> 16. jan. 2024 kl. 10:52 skrev Jan Høydahl <jan....@cominvent.com>:
>
>>> 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
> disabled and .disabled is used when default is enabled.
>
>>> managed.schema.mutable
>>
>> In this case (and likely others if I found one), there is no production
>> code containing this string. It is only a test config file containing
>> ${managed.schema.mutable} and probably test code that sets it. I don't
>> think we should put these in the list; the list is long enough as it is.
>
> Yep, I moved that line down to the "Test code" section of the table.
> I should have filtered my regex scan on non-test code..
>
>>> disable.configEdit. => solr.configset.edit.disabled
>> We should then broaden its use to cover the configset broadly, thus block
>> the schema edit API and maybe more. Right now it only covers mutability of
>> solrconfig.xml (via a JSON overlay). I'm good with that, but it increases
>> the scope.
>
> Yes, self descriptive naming is a goal. Rather change the names in this
> effort than change the functionality.
>
> Jan
