A solr-user list discussion led to some general thoughts about Solr that
I think need some further discussion. I'm ready to open an issue, I
just thought it might be better to define a direction first.
Some of the option/attribute names in config files aren't
self-descriptive, or have become not quite correct due to Solr's
evolution. One example is "instanceDir" but there are probably others.
I'm not sure that "instanceDir" was ever a good name. It probably made
complete sense when multicore first came into being, as it was meant to
replace multiple instances of Solr. Coming up with a better name is a
little tricky. A simple and currently relevant replacement would be
"coreDir" ... but if you're using SolrCloud, Jack Krupansky has put
forth some names that might be better: replicaDir, shardReplicaDir, or
even the wordy but extremely accurate collectionShardReplicaDir.
In recent years, Solr has evolved from multicore-capable to multicore in
even the simple example. If we have a similar migration so that all
Solr installations are SolrCloud installations, then having replicas
instead of cores (replacing instanceDir with replicaDir) might be the
right way to go. Will we ever have a larger abstraction than
collections? If we think that could ever happen, we should probably
think of a name for it.
I think that we need to start a general overhaul of various identifiers
in config files and APIs, planning ahead to accommodate future
(in)sanity. Because it could be extremely disruptive to ongoing
development, that probably needs to happen in a branch.
Thanks,
Shawn
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
