Piotr,
The 'unordered' flag allows spans to be overlapping and still be a match.
I believe this is a feature.
It may seem unusual for a term to be 'near' itself, but it may be more
intuitive if you consider spans that are more than one term long.
spanNear(
[spanNear([contents:test, contents:
Martin,
Note that the documents within each index segment (leaf context) are zero
indexed. Meaning that each segment in your index will contain a different
document with a segment-relative docId of 0.
When working inleaf context, you can calculate a document's absolute docId
with something like:
Hi David,
I'm not an expert, but I've climbed through the consumers myself in the
past. The big limit is that the full postings for a document or document
block must fit into memory. There may be other hidden processing limits
(ie. memory used per-field).
I think it would be possible to create
David,
Any document that matches a MUST_NOT clause will not match the
BooleanQuery. By definition.
This means that "maximumNumberMustNotMatch" is effectively hardcoded to
zero.
-Greg
On Wed, Apr 16, 2014 at 3:59 PM, David Stimpert wrote:
> Hello,
> I have found useful functionality in Boolea
BooleanQuery with a 'MUST_NOT' BooleanClause.
3.) Add the negating BooleanClause to a second BooleanQuery.
-Greg
On Thu, Apr 17, 2014 at 10:40 AM, Gregory Dearing wrote:
> David,
>
> Any document that matches a MUST_NOT clause will not match the
> Boolean
Glen,
Lucene isn't relational at heart and may not be the right tool for
what you're trying to accomplish. Note that JoinQuery doesn't join
'left' and 'right' answers; rather it transforms a 'left' answerset
into a 'right' answerset.
JoinQuery is able to perform this transformation with a single
Michael,
Note that the index doesn't contain any special information about
block-join relationships... it uses a convention that child docs are
indexed before parent docs (ie. the root doc in each hierarchy has the
largest docId in its block).
This means that it can 'join' to parents just by comp
's parent
is the closest parent docId that is greater than or equal to the child's
docId."
>
> I agree that the solution to my problem (without changing Lucene) is to
index the parent doc fields in a new child doc (we use a docType field to
distinguish -- changing the names o
James,
I haven't actually ran your example, but I think the source problem is that
your source query ("NT:American") is hitting documents that have no
children.
The reason the exception is so weird is that one of your index segments
contains zero documents that match your filter. Specifically, t
Jim,
I think you hit the nail on the head... that's not what BlockJoinQueries do.
If you're wanting to search for children and join to their parents... then
use ToParentBlockJoinQuery, with a query that matches the set of children
and a filter that matches the set of parents.
If you're searching
queries
<http://mail-archives.apache.org/mod_mbox/lucene-java-user/201412.mbox/%3ccaasl1-_ppmcnq3apjjfbt3adb4pgaspve-8o5r9gv5kldpf...@mail.gmail.com%3E>
-Greg
On Wed, Jan 21, 2015 at 7:59 PM, Michael Sokolov <
msoko...@safaribooksonline.com> wrote:
> On 1/21/2015 6:59 PM, Gregory Dearing
Hey Mike,
My fault... I wasn't paying attention and thought I was replying to a
response from James. No wonder it reminded me of our last conversation. :)
-Greg
On Thu, Jan 22, 2015 at 10:37 AM, Michael Sokolov <
msoko...@safaribooksonline.com> wrote:
> Yeah I know -- we've been around this bl
Hi Ali,
The short answer to your question is... there's no good way to create a
score from your result string, without using the Lucene index, that will be
directly comparable to the Lucene score. The reason is that the score
isn't just a function of the query and the contents of the document. I
13 matches
Mail list logo
