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 folder and tried to deduce some commonality and structure. I also enumerated all current sysProps used in the codebase (by scanning src for various System.getProperty, Boolean.getBoolean, EnvUtils.getProp variations). That is the second table on the page. Looking at all those system property names we have today is depressing, they are all over the place and 157 in number (although some are zk, hadoop or java owned and some relate to tests). I did a small stab on mapping those old props to a new proposed name, but the list is looong, so good with some collaboration on this. I experience that the shape of the hiearchy molds as I encounter more real-life examples. And there are tons of decisions, e.g. wether we should force solr.security as a prefix for all things security or to keep the shorter solr.auth.*. Same with solr.search.* It is also encouraging to see the list of existing solr.xxx keys in use that are already well structured (solr.jetty.keystore.password, solr.kerberos.keystore.password, solr.log.level etc). Jan > 11. jan. 2024 kl. 03:36 skrev David Smiley <dsmi...@apache.org>: > > On Tue, Jan 9, 2024 at 9:49 AM Jan Høydahl <jan....@cominvent.com > <mailto: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.
