The crux of the issue seems to be supporting multiple indexes within a
single JVM. This has come up before, and personally i'm still in favor of
implimenting this via multiple webapps in the same servlet container,
rather then a single webapp with many seperate configs/schemas/cores that
it chooses between...
http://www.nabble.com/Re%3A-Multiple-indices-p3540026.html
you mentioned...
: I think the value of the objectType is this true independence. If you
: are indexing similar data, use a field on your data. If your data sets
: are truly different, use a different object type.
...there is still some dependency there, unless you add a similar
objectType sectioning to the solrconfig -- there might be some query
handlers that i only want for one index but not others, or
newSearcher/firstSearcher listeners i only want for one index, etc...
having truely seperate webapsp gives you all the benefits of independency,
plus the benefit of a single shared JVM with a shared memory pool
I'm still confused however about why you want multiple indexes in your
specicic use case, you mention...
: In our case, there is no relationship between the multiple indices,
: but I do see value here (more on this below). In our specific case, we
: have a one to one mapping between a database table and a Lucene index
: and have not needed to search across tables.
but then you also said..
: address. One approach is to introduce a "partitionField" that
: SOLR would use to figure out if a new index is required. For each
: unique value of the partitionField, we create a separate physical
: index. If the query does NOT contain a term for the
: partitionField, we use a multi reader to search across all
: indexes. If the query DOES contain the term, we only search
: across those partitions.
...which confuses me. I also don't see how the partitionField idea could
work cleanly, because i can't think of anyway you could safely use a
MultiReader (or even a MultiSearcher) accross indexes that had differnet
schemas ... even if field names were the same, they might have been
analyzed completely differnetly, or use field types that encode the terms
in non-uniform ways.
are we discussig two differnet use cases?
1) support for multiple indexes with heterogeneous schemas in the same
JVM for better memory management (but with no interaction at query
time)
2) support for multiple indexes using hte same index in the same JVM for
better partitioning, with query time access to either a multireader
across all, or a single reader of an individual partition.
...if so, perhaps the two use cases should be solved in differnet ways:
multiple webaps for #1, and some new config/schema options and a new
SolrQueryRequest.getSearcher(String partition) method for #2.
-Hoss
