How would I go about altering lucene so that the index is saved to a
database instead?
(or has it been done? Wouldn't want to reinvent the wheel there.)
--
This email is confidential and may be privileged. If you are not the intended
recipient,
[ http://issues.apache.org/jira/browse/LUCENE-483?page=all ]
Hoss Man updated LUCENE-483:
Attachment: LUCENE-483.patch
patch containing test changes demonstrating the problem, and the fix in both
QueryParser.jj and QueryParser.java
> QueryParser.getFieldQu
QueryParser.getFieldQuery(String,String) doesn't set default slop on
MultiPhraseQuery
-
Key: LUCENE-483
URL: http://issues.apache.org/jira/browse/LUCENE-483
Project: Lucene - Java
Ty
[ http://issues.apache.org/jira/browse/LUCENE-478?page=all ]
Steven Rowe updated LUCENE-478:
---
Attachment: StandardTokenizer.jj.diff
Patch addressing the above-described issues
> CJK char list
> -
>
> Key: LUCENE-478
> URL: ht
[
http://issues.apache.org/jira/browse/LUCENE-478?page=comments#action_12361804 ]
Steven Rowe commented on LUCENE-478:
There are six classes of issues:
1. A character range in StandardTokenizer.jj that is missing in
John's list, and should be left as-is
If you'd consider using a MemoryIndex for this, I'd recommend also
having a look at nux.xom.pool.FullTextUtil and
nux.xom.pool.FullTextPool, adding smart caching for indexes, queries
and results on top of a MemoryIndex. With some luck this (or some
variant of it) could help speed up your us
Yes, that's a good start. Your patch does not handle deletions
correctly. If a segment has had deletions since it was opened then its
deletions file needs to be re-read. I also think returning a new
IndexReader is preferable to modifying one, since an IndexReader is
often used as a cache key
: This example code looks interesting. If I understand
: correctly using this approach requires that builders
: like the "q" QueryObjectBuilder instance must be
: explicitly registered with each and every builder that
: consumes its type of output eg BQOB and FQOB. An
correct.
: provider for the
I proposed and posted a patch for this long ago. Only thing missing would be
some sort of reference courting for segments (rather than the 'stayopen'
flag).
/**
* reopens the IndexReader, possibly reusing the segments for greater
efficiency. The original IndexReader instance
* is closed, a
Amol Bhutada wrote:
If I have a reader and searcher on a indexdata folder and another
indexwriter writing documents to the same indexdata folder, do I need to
close existing reader and searcher and create new so that newly indexed
data comes into search effect?
[ moved from user to dev list]
This example code looks interesting. If I understand
correctly using this approach requires that builders
like the "q" QueryObjectBuilder instance must be
explicitly registered with each and every builder that
consumes its type of output eg BQOB and FQOB. An
alternative would be to register "q" jus
Yes, I've found MemoryIndex to be very fast for this
kind of thing. This contribution can be used to
further optimize and shortlist the queries to be run
against the new document sat in MemoryIndex.
___
To help you stay sa
Karl,
Have you considered the MemoryIndex for this sort of thing? I've
thought that it would make for an elegant way to handle this sort of
"agent" or notification service such that new documents get indexed
normally, but also a single document goes into a MemoryIndex and is
matched agai
Hello list,
I wrote a search agent thingy for Lucene. It was built to handle huge
amounts of agents.
Rather than one query per agent to find out if the new document is
interesting or not, agent trigger queries are stored in an index that
is queried with the tokens of a new document.
Sin
: I'd still like to keep the parser core reasonably generic (ie
: java.lang.Object rather than Query or Filter) because I can see it being
: used for instantiating many different types of objects eg requests for
: GroupBy , highlighting, indexing, testing etc.
: As for your type-safety requiremen
15 matches
Mail list logo
