: I agree segmentInfos are not needed in this case. But it's used in
: aquireWriteLock(). What should we do?
This is one of the reasons why i was suggesting in a java-dev thread that
*all* of the refrences to SegmentInfos be refactored out of IndexReader
and into the subclasses -- any attempt to
Right now I am very confused.
I agree segmentInfos are not needed in this case. But it's used in
aquireWriteLock(). What should we do?
--
Chris Lu
-
Instant Scalable Full-Text Search On Any Database/Application
site: http://www.dbsight.net
demo: http://search.dbsight.com
: I found out in latest MultiReader.java, the "SegmentInfos" is set to null.
: However, segmentInfos are used in several places, causing NPEs.
: For example, in IndexReader.acquireWriteLock(),
MultiReader was refactored into two classes: MultiReader which is now only
constructed from other reade
Hi, Eric, I think I have the same problem.
I found out in latest MultiReader.java, the "SegmentInfos" is set to null.
public MultiReader(IndexReader[] subReaders) throws IOException {
super(subReaders.length == 0 ? null : subReaders[0].directory(),
null, false, subReaders);
}
H
Eric Louvard wrote:
> Hello while calling IndexReader.deletedoc(int) I am becomming a NPE.
>
> java.lang.NullPointerException
>at
> org.apache.lucene.index.IndexReader.acquireWriteLock(IndexReader.java:658)
>at
> org.apache.lucene.index.IndexReader.deleteDocument(IndexReader.java:6
A three field boolean query isn't very complex, so I don't
think that's a problem. Although it does depend a bit upon
how many terms you allow.
But I'd try the simplest thing first, which would be to put
all the terms in a fulltext field as well as in individual terms.
Then get some performance m
Hi everyone,
My question : i have medias with a "title" field and a "caption"
field and a "keywords" field.
I want to be able to search in those 3 fields at the same time. For
example, if i search "black car" the boolean query looks like this
combination of termqueries:
(title=
Ahhh, I was assuming you didn't need to look at all clusters.
Oops.
That said, the question is really whether this is "good enough"
compared to re-indexing, and only some tests will determine that.
I was surprised at how quickly a *large* number of ORs was
processed by Lucene.
You could also thin
do you mean to say that we generate a compound query by AND ing the original
query with a query like
( (cluster_id=0)^boost_cluster0 OR (cluster_id=1)^boost_cluster1...) )
But is this not inefficient considering that the number of clusters is in
hundreds ??
On 8/21/07, Erick Erickson <[E
One solution is to keep meta-data in your index. Remember that
documents do not all have to have the same field. So you could
index a document with a single field
"metadatanotafieldinanyotherdoc" that contains, say, a list of
all of your clusters and their boosts. Read this document in at
startup t
Is it possible to have multiple documents share a common boost?
An example scenario is as follows. The set of documents are clustered into
some set of clusters. Each cluster has a unique clusterId. So each document
has a cluster Id field that associates each document with its cluster. Each
cluster
On 8/21/07, Heba Farouk <[EMAIL PROTECTED]> wrote:
> the documents are not duplicated, i mean the hits (assume that 2 documents
> have the same subject but with different authors, so if i'm searching the
> subject, the returned hits will have duplicates )
> i was asking if i can remove duplicates
:S
If you have two hits, you have it two times in your index, simple as that. So,
you have two lucene Documents with the same subject, but with different
authors, and your search for subject, well, obviously you get 2 hits.
Check out luke, it will help you understand your index. Furthermore, y
the documents are not duplicated, i mean the hits (assume that 2 documents have
the same subject but with different authors, so if i'm searching the subject,
the returned hits will have duplicates )
i was asking if i can remove duplicates from the hits??
thanks in advance
Ard Schrijvers <[EMAIL
Hi,
Yes there are ways and workarounds to remove duplicates based on one
field. But, you should not need this if you don't index duplicates at
the first place. Just put a call to "delete" from index right before you
add the document to in.
Best Regards,
Kapil Chhabra
-Original Message-
Fr
Hello Heba,
you need some lucene field that serves as an identifier for your documents that
are indexed. Then, when re-indexing some documents, you can first use the
identifier to delete the old indexed documents. You have to take care of this
yourself.
Regards Ard
>
> Hello
> i would like
Hello
i would like to implement a suggest implementation (like google suggest) using
lucene. i actually tried using lucene and it was successfull but i was stuck in
some point which is returning a list of results to the user that have no
duplicates. my question is: is there any way i can remove
Hello while calling IndexReader.deletedoc(int) I am becomming a NPE.
java.lang.NullPointerException
at
org.apache.lucene.index.IndexReader.acquireWriteLock(IndexReader.java:658)
at
org.apache.lucene.index.IndexReader.deleteDocument(IndexReader.java:686)
In the acquireWriteLock m
18 matches
Mail list logo
