> I think SOLR needs to be able to support multiple Lucene indexes per WAR > deployment as well
Is this because single requests need to query across multiple indexes? Or do you have different document types that you don't want to stick in the same physical Lucene index? > With this idea, you could even imagine an application could upload a schema to > SOLR and have it create the index, etc. upon which you could then add > documents, etc. It's a slightly foreign use-case for me since our search collections are used to power websites (both content generation and relevancy-search). No one is going to share Solr servers, or even change much of anything on-the-fly. Any major changes require validation (performance and otherwise). What types of applications do you see this useful for? -Yonik On 4/26/06, Grant Ingersoll <[EMAIL PROTECTED]> wrote: > > > Erik Hatcher <[EMAIL PROTECTED]> wrote: > I've been mulling over the idea of having a single Solr instance > morph into system that can handle multiple client-defined schemas > (why not? Lucene itself can handle it) rather than a static XML file > and allow the schemas themselves to be retrievable (yes, I know it > already is). I'm still talking about a single Lucene index, but with > each Document given a "soup" name field and filters automatically > available to single out a specific soup. > > > I agree. > > I also don't think it is going to work well to have one webapp per > index/schema for those of us who want multiple indexes. I think SOLR needs > to be able to support multiple Lucene indexes per WAR deployment as well > (although your soup idea would work well too) and then allow the requests to > specify which index to use, maybe with some defaults. With this idea, you > could even imagine an application could upload a schema to SOLR and have it > create the index, etc. upon which you could then add documents, etc. No need > to do anything command line at all.
