Hi
Thank you for replying so quickly. I am very pleased as I have just started
down the road of implementing a solution which is very nearly exactly like the
one you describe below. It is good to know that I am not heading down a dead
end. I hadn't thought about the re-indexing thread
Hi,
we are using a very cautious method for batch upating.
We have long (hours) running updates on our index, but
complete reindexing would even be longer (days). But I
guess our strategy could be scaled down to hours or even
less.
So what we do is, we keep two instances
of the index. There
Hello, Erik.
EH On Apr 4, 2005, at 4:34 PM, Yura Smolsky wrote:
Hello, java-user.
I have documents with tokenized, indexes and stored field. This field
contain one-two words usually. I need to be able to search exact
matches for two words.
For example search John should return documents
On Apr 5, 2005, at 5:44 AM, Yura Smolsky wrote:
EH On Apr 4, 2005, at 4:34 PM, Yura Smolsky wrote:
Hello, java-user.
I have documents with tokenized, indexes and stored field. This field
contain one-two words usually. I need to be able to search exact
matches for two words.
For example search John
I would recommend not optimizing your index that often. Another solution is to
use the multisearcher and keep one fully optimized primary index, and an
unoptimized secondary index that you add to. Then search against both. During
off peak hours you could merge the secondary index onto your
If you take this approach, keep in mind that you will also need to
handle regular application shutdowns, and also try to catch some
crashes/errors, in order to flush your in-memory queue of items
scheduled for indexing, and write them to disk.
Feel free to post the code, if you want and can, so
As Lucene native language is Java it should be more natural to access its
functionalities through JSP; anyway the idea of accessing Lucene
functionalities seems interesting as PHP is perhaps most widely deployed
server side scripting language.
I think that the way to provide access to Lucene
Gusenbauer Stefan wrote:
Erik Hatcher wrote:
On Apr 3, 2005, at 3:33 PM, Gusenbauer Stefan wrote:
Sorry for beeing late!
Only the test code wouldn't be very useful for understanding because
there are a lot of dependencies in the other code. I can explain what
I do: I open an
Was there any later thread on the QueryParser supporting open ended
range queries after this:
http://www.mail-archive.com/lucene-user@jakarta.apache.org/msg07973.html
Just curious. I plan on overriding the current getRangeQuery() anyway
since it currently doesn't run the endpoints through the
On Apr 5, 2005, at 2:49 PM, Yonik Seeley wrote:
Just curious. I plan on overriding the current getRangeQuery() anyway
since it currently doesn't run the endpoints through the analyzer.
What will you do when multiple tokens are returned from the analyzer?
Erik
For numeric fields, this will never happen.
For text fields, I could either
1) just use the first token generated (yuck)
2) don't run it through the analyzer (v1.0)
3) run it through an analyzer specific to range and prefix queries (post v1.0)
Since I know the schema, I can pick and choose
:
: is it possible to filter the hits returned from a certain query?. for
: example if I have a search like this:
: Query searchQuery = queryParser.parse( query );
: Hits results = m_searcher.search( searchQuery );
: is there a way to use the results and find out how many of the
he wiki appears to have undergone some style cahnges recently, the layout
is a lot different now (and in my opinion: cleaner) but a side effect
seems to be that some page formatting which used to work no
longer does
Specifically, subSection headings that have leading whitespace, ie...
==
Otis Gospodnetic wrote:
If you take this approach, keep in mind that you will also need to
handle regular application shutdowns, and also try to catch some
crashes/errors, in order to flush your in-memory queue of items
scheduled for indexing, and write them to disk.
Feel free to post the code,
14 matches
Mail list logo
