On 3/28/2013 4:23 PM, Mark Miller wrote:
True - though I think for 4.2. numShards has never been respected in the <cores
def's for various reasons.
In 4.0 and 4.1, things should have still worked though - you didn't need to
give numShards and everything should work just based on configuring different
shard names for core or accepting the default shard names.
In 4.2 this went away - not passing numShards now means that you must distrib
updates yourself. There are various technical reasons for this given new
features that are being added.
So, you can only really pre configure *one* collection in solr.xml and then use
the numShards sys prop. If you wanted to create another collection the same way
with a *different* number of shards, you would have to stop Solr, do a new
numShards sys prop after pre configuring the next collection, then start Solr.
Not really a good option.
And so, the collections API is the way to go - and it's fairly poor in 4.2 due
to it's lack of result responses (you have to search the overseer logs). It's
slightly better in 4.2 (you will get some response) and much better in 4.2.1
(you will get decent responses).
Now that it's much more central, it will continue to improve rapidly.
Can't you leave numShards out completely, then include a numShards
parameter on a collection api CREATE url, possibly giving a different
numShards to each collection?
Thanks,
Shawn
