You could always purchase the PDF from www.manning.com.
This book is essential in my view. Its also one of the clearest most engaging
IT books I've ever read.
- Original Message
From: digby [EMAIL PROTECTED]
To: java-user@lucene.apache.org
Sent: Tuesday, 6 June, 2006 11:55:26 AM
Hi everyone, just wondered if I could get peoples opinions on a design issue.
I am designing a system that uses broker / search server pattern. Each search
server will be responsible for searching a particular application that will
consist of multiple indexes. Initially, these servers will
@lucene.apache.org; Marc Dauncey [EMAIL PROTECTED]
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
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
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
i think thats meant to be partition which would definitely make sense in the
context of using a multisearcher to search logical domain-specific partitions
within an app.
- Original Message
From: Erik Hatcher [EMAIL PROTECTED]
To: java-user@lucene.apache.org
Sent: Thursday, 18 May,
I'm working on designing this kind of meta configuration on top of some Lucene
indexes right now. The company I work for has several different products
which have to be indexed and searched, each with their own field list.
Sometimes products will map to many individual Lucene indexes.
The
I'm planning to write a listener which will recieve messages from our indexing
application via SOAP - the message will indicate which indexes have been
updated as we will be using quite a few separate lucene indexes. No point
dropping all the searchers (and any caches, filters etc) if only one
Thank you for all your thoughts on this - I think we will go the route of
having two copies for each index, a working copy and the one the searchers use.
If we start off indexing like this it shouldn't be too hard to keep them in
sync.
Thanks again,
Marc
- Original Message
From:
I read somewhere recently (maybe even on this list) a
recommendation to requery each time for successive
pages as this avoids some of the complexity involved
in session management. Whats peoples view of this?
Marc
--- karl wettin [EMAIL PROTECTED] wrote:
27 apr 2006 kl. 20.44 skrev Jean
the query and you're
re-querying, you will
maybe get confused about new docs :-)
Hannes
Marc Dauncey schrieb:
I read somewhere recently (maybe even on this
list) a
recommendation to requery each time for successive
pages as this avoids some of the complexity
involved
in session
. Rather than bringing the
entire hits once in the
memory then displaying it as and when the user is
clicking on the next
button. It would be very kind of you if you give me
a detailed view
about this..
Regards,
Kinnar
-Original Message-
From: Marc Dauncey [mailto:[EMAIL PROTECTED
it.
Anyway, I hope this helps.
Jeremy
On Apr 17, 2006, at 2:53 PM, Marc Dauncey wrote:
Hi everyone,
I'm currently designing a Lucene search system and
i'm
considering the indexing side of things.
Just wondered what kind of architecture people
have
adopted for indexing - are CHRON
solution with web
services to index on demand?
And has anyone used Quartz to schedule Lucene index
updates? Sounds like an interesting product in this
context.
Many thanks
Marc Dauncey
___
Yahoo
14 matches
Mail list logo
