And "multicore" is one of my examples of what should "go away" as a legacy
term. It should be simply "multiple collections", independent of whether it
is single node and single-shard, regardless of whether cloud/"distrib" is
involved.
Actually, "multicore" appears to be two distinct use cases:
1. Multiple collections.
2. Replication.
-- Jack Krupansky
-----Original Message-----
From: Shawn Heisey
Sent: Monday, May 06, 2013 12:58 PM
To: dev@lucene.apache.org
Subject: A couple of high level Solr issues
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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
