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", "node" or whatever set of top-level
components make sense. Then I guess shard split would be
"solr.collection.shard.split.checkDiskSpace.enabled" or similar. However, I
find it hard to find good generic top-level categories for Solr that are
consise and no overlapping.
> On a related note, I've been thinking it'd be wonderful if Solr
> automatically had sys-prop/env-var overrides for any configuration element
> without requiring a dollar-curley-bracket use.
That would be wonderful, and would likely require similar centralization and
standardization.
> Are you saying the camel case is a problem?
No necessarily. The concern was that there should be a well-defined way to
translate an SOLR_ENV_VAR into system property, so we don't need to touch
bin/solr[.cmd] every single time. And it would be hard for an algorithm to know
that it should translate SOLR_SHARD_SPLIT_CHECK_DISK_SPACE_ENABLED env.var into
the exact combination of dot separation and camelCase used above. An
alternative could be using a combination of underscore and dash, such as
"SOLR_SHARD-SPLIT_CHECK-DISK-SPACE_ENABLED", where we translate underscore with
dot and dash with Camelcase. We'd need to disallow dash in property names
then...
Jan
> 7. jan. 2024 kl. 17:49 skrev David Smiley <dsmi...@apache.org>:
>
> 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 follows is
> "checkDiskSpace.enabled. I dislike ".enabled" in general but not a big
> deal. Are you saying the camel case is a problem? Is it a problem in the
> module part "shardSplit"? The current structure is clear (separation of
> the module/category from the individual toggle name); disallowing camel
> case in a system property and converting to periods would look worse, but
> alas, I guess we can't have everything.
>
> On a related note, I've been thinking it'd be wonderful if Solr
> automatically had sys-prop/env-var overrides for any configuration element
> without requiring a dollar-curley-bracket use. This would result in
> standardization and more easily allow near empty configurations by default;
> something we don't quite have. An example:
> in solrconfig.xml, <config> parent element, we have this today:
> <directoryFactory name="DirectoryFactory"
>
> class="${solr.directoryFactory:solr.NRTCachingDirectoryFactory}"/>
> Imagine instead not specifying this at all. The default logic would
> instead read the class from the sys prop: "solr.config.directoryFactory".
> The "config" part is because that's the root element of this file.
>
> Here's another example:
> <updateHandler class="solr.DirectUpdateHandler2">
> <commitWithin>
> <softCommit>${solr.commitwithin.softcommit:true}</softCommit>
> </commitWithin>
> </updateHandler>
>
> Again, imagine not specifying this at all. Instead, the default would be
> read from "solr.config.updateHandler.commitWithin.softCommit".
>
>
> On Fri, Jan 5, 2024 at 11:15 AM Jan Høydahl <jan....@cominvent.com> wrote:
>
>> Hi,
>>
>> Happy New Year to all!
>>
>> Finally https://issues.apache.org/jira/browse/SOLR-15960 Unified use of
>> system properties and environment variables is now merged!
>> It exports all SOLR_FOO and ZK_FOO env.vars to be available to the Solr
>> Java process and maps them to sys.prop without need for explicit maping in
>> bin/solr[.cmd].
>>
>> Please take it for a spin, and if you find simplifications that can be
>> done in bin/solr[.cmd] scripts or docs, feel free to grab those.
>>
>>
>> I'm planning a followup related to sysprop naming convention in
>> https://issues.apache.org/jira/browse/SOLR-17111
>> Proposing a strict solr.foo.bar naming, aligning with env name
>> SOLR_FOO_BAR instead of our current solr.fooBar camelCase props.
>> The plan is to support both old and new keys in in 9.x (e.g. both
>> "disableAdminUI" and "solr.admin.ui.disabled") and only new from 10.0.
>> Q: Wil this be such a big change that both variants should work throughout
>> the 10.x series as well?
>>
>>
>> Next, I'd love to consider semantic property names. Now we have a mix of
>> randomly chosen property names. Some examples:
>> metricsEnabled
>> solr.enableStreamBody
>> enable.packages
>> solr.clustering.enabled
>> solr.shardSplit.checkDiskSpace.enabled
>> solr.log.requestlog.enabled
>> I'd love for us to qualify these with module/submodule, so we get some
>> semantic naming structure like
>>
>> solr.<module>.<submodule>.<key>=foo
>> E.g. enable.packages would then be solr.packages.enabled (instead of
>> simply solr.enable.packages)
>>
>> To do this across the entire set of solr properties is a much bigger
>> change than SOLR-17111. So I propose to tackle only the non-standard ones
>> first, and select new names case by case.
>>
>> If you like the proposal of some standardized naming hierarchy across all
>> properties, that is probably something that deserves a design document or a
>> SIP..
>>
>> -Jan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org
For additional commands, e-mail: dev-h...@solr.apache.org
