lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Dauncey <marc_daun...@yahoo.com>
Subject Re: Web services for querying and return of results
Date Wed, 24 May 2006 08:40:44 GMT
Thanks for the reply everyone - useful advice.  We are already engaged in designing a solution
around Lucene, the web services in that context was the thing I specifically needed advice
on.

Solr sounds very interesting though - how do you maintain the cache?  Are you storing filters?
 And how do you persist these, via the session or using some kind of register?  I was considering
designing something like this but felt that state management was something I wanted to avoid
doing if possible, because it limits how many users we can service, if a lot of data is being
kept round for caching.  Would be very interested in how you managed to do this, and still
make Solr scalable.

I know this is kind of wandering off the point of web services, but grateful to share your
knowledge and experience!

Marc

----- Original Message ----
From: Chris Hostetter <hossman_lucene@fucit.org>
To: java-user@lucene.apache.org; Marc Dauncey <marc_dauncey@yahoo.com>
Sent: Tuesday, 23 May, 2006 8:37:43 PM
Subject: Re: Web services for querying and return of results


The usage you describe sounds perfectly suited for Solr ... without even
needing heavy customizations or custom plugins...

: Hi Erik, many thanks for your response - a typical search application
: that will consume the web service will typically want to display 25
: results per page.  Most users will only be interested in the first few
: pages, but there are certain searches with users that will want to
: examine many pages of results.

Solr's standard request handler has options for specifying that you want
results 1-25, or 26-50, etc...

: I was hoping to avoid maintaining hits on the session so pagination will
: requery the index.  The options are to either to render a load of
: documents as xml and then let the client cache the results itself, or
: simply to return 25 results for each subsequent page.

Solr has internal caching with "smart warming" ... not only will the
results of a search still be there if your user comes back and asks for
page#2, even if you update the index and delete some documents and add
some new documents Solr will rerun your recent searches in the background
to "warm" the new cache.

: I guess it also depends on the amount of text being returned in fields -
: we have probably a core set of around 10 fields returned for every query
: and then a larger set of fields that are used for very particular
: searches.

Solr's standard request handler lets you specify which stored fields you
want by name at query time.

http://incubator.apache.org/solr/
http://incubator.apache.org/solr/tutorial.html


-Hoss


---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org





---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org


Mime
View raw message