Marc,
To me it sounds like Lucene may certainly be a good tool for what you describe.
In terms of Hit caching. Depending on how exactly you are using it,
lucene can be insanely fast, making hit caching not necessary. I
believe it also does internal caching to some degree as long as you
are using single IndexSearcher object instance.
Somewhat related to your caching question...One thing I've been told
and strongly believe from experience is that due to the raw power and
speed of Lucene, sometimes the brute force approach to solving a
search problem is faster in terms of both implementation and
performance when compared to engineering an elegant solution. For
many tasks, Lucene is really that fast.
If nothing else, it's worth putting together a prototype to see it
works well for what you need. From your brief description, Lucene may
be perfect.
-Pete
On 5/23/06, Marc Dauncey <[EMAIL PROTECTED]> wrote:
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.
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.
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.
Both search clients and server will be internal to the company - although its a
possibility it could be opened up externally at a later date.
Does this sound like an appropriate use of the technology?
Thanks
Marc
----- Original Message ----
From: Erik Hatcher <[EMAIL PROTECTED]>
To: java-user@lucene.apache.org
Sent: Tuesday, 23 May, 2006 6:51:25 PM
Subject: Re: Web services for querying and return of results
On May 23, 2006, at 1:41 PM, Marc Dauncey wrote:
> Has anyone used this as a delivery mechanism for Lucene query results?
>
> A quick search on Google reveals a Lucene Web Service project on
> SourceForge, but what i want to know is whether people on the list
> know of any big drawbacks, specifically, how well could I expect
> this to perform, as compared to passing back a Hits object to clients.
>
> The advantages I can see advocating SOAP are light coupling of
> search clients and servers, plus ease of consumption with lots of
> systems, devices, cocoon etc.
>
> Does anyone use this in their application and how have you found it?
The web applications I've built around Lucene mostly all support "web
services" (lower cased). Atom, RSS, OpenSearch, and Solr's custom
XML all qualify. I'm currently leveraging Solr in a Ruby on Rails
front-end and it is working very well. SOAP works too, but I prefer
a lighter-weight mechanism. With all of these, care must be taken to
only send back a paged subset of matching documents, of course.
There are many factors involved in determining how any kind of web
service wrapper around Lucene will perform, so its hard to say. The
real question is: does it perform well enough in your environment?
Erik
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
