On Tue, Jan 9, 2024 at 9:49 AM Jan Høydahl <jan....@cominvent.com> 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 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. > So the module can't be camel-case but checkDiskSpace can? What about hyphens in a sys prop, mapped to an underscore in an env var? > "solr.collection.shard.split.checkDiskSpace.enabled" Not bad. I bet it's hard to find good generic top-level categories. Feel free to take a stab at this and share for review. It doesn't need to be perfect, just not nausea inducing :-) > > 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... > Alternatively simply normalize both sys props and env vars using the same scheme. In theory it would allow crazy variation but if we only document each named toggle a certain way then it doesn't matter.
