: I definitely like the idea of support for multiple indexes based on
: partitioning data that is NOT tied to a predefined element named
: objectType. If we combine this with Chris' mention of completing the
: work to support multiple schemas via multiple webapps in the same
: servlet container, then I no longer see an immediate need to have more
: than one schema per webapp. The concept would be:
Yonik already added support for multiple webapp instances (with unique
schemas) to the Near Term task list ... i've also added a
brainstorming page to the wiki with some ideas for implimenting index
partitioning to the "Ideas for the future" section...
http://wiki.apache.org/solr/TaskList
http://wiki.apache.org/solr/IndexPartitioning
...the more i think about though, the less i'm convinced this is
absolutely neccessary. i have a feeling that the built in DocSet caching
solr does and the search methods that allow you to filter by a DocSet (or
a query which is converted to a DocSet) would proably be "fast enough"
most times.
I would encourage you to experiment more with SOlr and test out it's
performance before assuming you have to get down into the nitty gritty
stuff and partition hte index (just becuase it improved the performance of
straight Lucene, doesn't mean Solr's built in caching mechanisms aren't
already better)
-Hoss
