lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vadim Kirilchuk (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (LUCENE-4768) Child Traversable To Parent Block Join Query
Date Mon, 11 Feb 2013 09:17:12 GMT

    [ https://issues.apache.org/jira/browse/LUCENE-4768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13575689#comment-13575689
] 

Vadim Kirilchuk edited comment on LUCENE-4768 at 2/11/13 9:16 AM:
------------------------------------------------------------------

Hi, it's a very long story, but in a few words i have query like
TPBQJ(type:parent;
    +type:child +(f1:A or f1:B or f2:A or f2:B)
)
and then i want to have both A and B in my match, so when i hit a doc i traverse matched scorers
and execute AB coverage check. And if i find such children, i skip other childs and go to
the next parent doc. It's very tricky, i know.

But the general idea i talking about is that traversing all childs in nextDoc sometimes can
be a waste of time. Moreover i don't see any problems to have low level child traversable
query as a base and regular tpbjq as a special case. 


                
      was (Author: vkirilchuk):
    Hi, it's a very long story, but in a few words i have query like
TPBQJ(type:parent;
    +type:child +(f1:A or f1:B or f2:A or f2:B)
)
and then i want to have both A and B in my match, so when i hit a doc i traverse matched scorers
and execute AB coverage check. And if i find such children, i skip other childs and go to
the next parent doc. It's very tricky, i know.

But the general idea i talking about is that traversing all childs in nextDoc sometimes can
be a waste of time.


                  
> Child Traversable To Parent Block Join Query
> --------------------------------------------
>
>                 Key: LUCENE-4768
>                 URL: https://issues.apache.org/jira/browse/LUCENE-4768
>             Project: Lucene - Core
>          Issue Type: Improvement
>          Components: core/query/scoring
>         Environment: trunk
> git rev-parse HEAD
> 5cc88eaa41eb66236a0d4203cc81f1eed97c9a41
>            Reporter: Vadim Kirilchuk
>         Attachments: LUCENE-4768-draft.patch
>
>
> Hi everyone!
> Let me describe what i am trying to do:
> I have hierarchical documents ('car model' as parent, 'trim' as child) and use block
join queries to retrieve them. However, i am not happy with current behavior of ToParentBlockJoinQuery
which goes through all parent childs during nextDoc call (accumulating scores and freqs).
> Consider the following example, you have a query with a custom post condition on top
of such bjq: and during post condition you traverse scorers tree (doc-at-time) and want to
manually push child scorers of bjq one by one until condition passes or current parent have
no more childs.
> I am attaching the patch with query(and some tests) similar to ToParentBlockJoin but
with an ability to traverse childs. (i have to do weird instance of check and cast inside
my code) This is a draft only and i will be glad to hear if someone need it or to hear how
we can improve it. 
> P.s i believe that proposed query is more generic (low level) than ToParentBJQ and ToParentBJQ
can be extended from it and call nextChild() internally during nextDoc().
> Also, i think that the problem of traversing hierarchical documents is more complex as
lucene have only nextDoc API. What do you think about making api more hierarchy aware? One
level document is a special case of multi level document but not vice versa. WDYT?
> Thanks in advance.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message