Anything could be in the client's sub-index (for example, say if searches
are being done against a large mail archive one may want to keep an local
index of the just the user's to/from as that may be the most often searched
data).
Building the index on the server than transferring it across to th
Sorting on an integer field can be done using any of the Searcher.search
methods which take a "Sort" object.
-Hoss
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
On Aug 28, 2006, at 9:52 AM, d rj wrote:
The primary reason for building a smaller client side sub-index is
quality
of service. Building a client side index will avoid both network
latency
and network outage issues. Rather than have the client application
attempt
to query the server's Lu
Jason Polites wrote:
It was definately NTFS, unfortunately it was a while ago, and most of the
code has changed.
Basically I had a multi-threaded app where multiple threads were writing to
the index (but exclusively... that is, I had my own locking mechanism
preventing concurrent writes).
In a
(excuse the semi-appropriate forum to make this comment in - but it is very
brief and may actually help improve the final Lucene-based app)
You may also like to import popularity data from Amazon using their open
APIs and mix the relevancy between your own popularity score and theirs.
Dejan (affi
Hello Erik-
The primary reason for building a smaller client side sub-index is quality
of service. Building a client side index will avoid both network latency
and network outage issues. Rather than have the client application attempt
to query the server's Lucene index for search results I woul
It was definately NTFS, unfortunately it was a while ago, and most of the
code has changed.
Basically I had a multi-threaded app where multiple threads were writing to
the index (but exclusively... that is, I had my own locking mechanism
preventing concurrent writes).
In a separate JVM, I had a
Jason Polites wrote:
Yeah.. I had a think about this, and I now remember why I originally
came to
the conclusion about cross-JVM access.
When I was adding documents to the index, and searching at the same time
(from a different JVM) I would get the occassional (but regular)
FileNotFoundExceptio
Yeah.. I had a think about this, and I now remember why I originally came to
the conclusion about cross-JVM access.
When I was adding documents to the index, and searching at the same time
(from a different JVM) I would get the occassional (but regular)
FileNotFoundException.
I don't recall the
I want to implement a specific search based on a selling rate.
Let me explain this:
I have a book collection in my store.
I index my books like that:
- One Lucene Document by book
- Two Lucene Fields in the document
- TITLE OF THE BOOK
- KEYWORDS OF THE BOOK
The keyword field i
10 matches
Mail list logo
