I’m able to define this problem with a more discrete example including the
two classes below. This suggests a bug and unless someone has clearer
direction on this implementation I’m planning to file it as one.
package org.lexevs.lucene.prototype;
import java.io.IOException;
import java.nio.file
I’m guessing this issue may be related to the SOLR error described here:
https://issues.apache.org/jira/browse/SOLR-7606. I can find at least one
group of documents with a missing parent in my generated index. This
doesn’t explain why I didn’t see a similar issue in 4.10.4. I can see
that the Bi
Well it’s clear that this is just giving a return value of
Integer.MAX_VALUE for the parentDoc. Given the recent changes noted here:
https://issues.apache.org/jira/browse/LUCENE-6021 where FixedBitSet now
returns Integer.MAX_VALUE instead of -1 I wonder if a bug wasn’t
introduced to the BlockJoin
One correction, it looks like the parentBits call has 4823680 passed to it
to generate the erroneous docId.
On 6/5/15, 10:34 AM, "Bauer, Herbert S. (Scott)"
wrote:
>I should mention that this worked in 4.10.4 using a very similar code
>base. -scott
>
>On 6/4/15, 4:51 PM, "Bauer, Herbert S. (Sco
I should mention that this worked in 4.10.4 using a very similar code
base. -scott
On 6/4/15, 4:51 PM, "Bauer, Herbert S. (Scott)"
wrote:
>I¹m working with Lucene 5.1 to try to make use of the relational
>structure of the block join index and query mechanisms. I¹m querying
>with the following
I’m working with Lucene 5.1 to try to make use of the relational structure of
the block join index and query mechanisms. I’m querying with the following
code:
IndexReader reader = DirectoryReader.open(index);
ToParentBlockJoinIndexSearcher searcher = new
ToParentBlockJoinIndexSearcher(reade
