On 4/18/06, Vish D. <[EMAIL PROTECTED]> wrote:
> Do we have a eta on " Allow multiple independent Solr *webapps* in the same
> app server"?
We've been discussing it on solr-dev
http://www.mail-archive.com/solr-dev%40lucene.apache.org/msg00292.html
> But, it makes sense to run a comparison against
Yonik/Chris,
Do we have a eta on " Allow multiple independent Solr *webapps* in the same
app server"?
After reading up, silently, on the many emails on this topic, I agree with
you that it would be worthwhile to test out the current implementation and
see how it performs. But, it makes sense to r
On 4/15/06, Bryzek.Michael <[EMAIL PROTECTED]> wrote:
> * Translate a table design in the database to an XML document that
> only defined the fields and their types for that table
Just so anyone new to Lucene/Solr isn't mislead by this thread...
Lucene (and hence Solr) documents don't need to b
M
To: solr-user@lucene.apache.org
Subject: RE: Interest in Extending SOLR
: One last note: last night, I did spend a bit of time looking into what
: exactly it would mean to add support for object types in SOLR. I
: modified the code base to support the object type tag in the schema,
: providing a wor
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
: 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, t
: One last note: last night, I did spend a bit of time looking into what
: exactly it would mean to add support for object types in SOLR. I
: modified the code base to support the object type tag in the schema,
: providing a working proof of concept (I'm happy to send a sample schema
: if anybody
solr-user@lucene.apache.org
Subject: Re: Interest in Extending SOLR
Michael,
I'm not sure that objectType should be tied to which index something
is stored in.
If Solr does evolve multiple index support, one usecase would be
partitioning data based on other factors than objectType
(docume
Hello there. I moved from Lucene to Solr and am thus far impressed with the
speed, even with the added XML transport necessary to send and receive data.
However, one thing I did like about the Lucene implementation was the
ability to specify indices for each invocation.
I agree with Michael
On 4/13/06, Chris Hostetter <[EMAIL PROTECTED]> wrote:
> This has come up before, and personally i'm still in favor of
> implimenting this via multiple webapps in the same servlet container
That would certainly be easier (and you bring up a good point about
probably wanting different solrconfigs f
Michael,
I'm not sure that objectType should be tied to which index something
is stored in.
If Solr does evolve multiple index support, one usecase would be
partitioning data based on other factors than objectType
(documentType).
It would seem more flexible for clients (the direct updater or quer
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 choos
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.
>
> We have tried using cached bitsets to implement this sort of
> approach, but have found that w
partitioned into much smaller sets (e.g. 1-10% of the total
document space), creating separate indexes gives us a much higher
boost in performance.
-Mike
-Original Message-
From: Yonik Seeley [mailto:[EMAIL PROTECTED]
Sent: Wed 4/12/06 11:54 AM
To: solr-user@lucene
Welcome Michael,
On 4/12/06, Bryzek.Michael <[EMAIL PROTECTED]> wrote:
> * Integrated support for partitioning - database tables can be
> partitioned for scalability reasons. The most common scenario for
> us is to partition off data for our largest customers. For
> example, imagine
15 matches
Mail list logo
