lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mikhail Khludnev (Commented) (JIRA)" <>
Subject [jira] [Commented] (SOLR-3076) Solr should support block joins
Date Mon, 13 Feb 2012 20:15:00 GMT


Mikhail Khludnev commented on SOLR-3076:


Thank you a lot for the fix! Pls, find replies for the points above:

* I think it's worth to start from the essential ability - "opening up end-user QP syntax",
and deliver fullfledged entity-relations schema later. I'm sure even this basic will be challenging
enough. After we will have a feedback for essential approach, it will be clear what to include
into the advanced one.

** Despite I propose to push it back, I have some thoughts about field names clash in ER-schema.
If we have one field interpreted diferently between searches: first time SIZE is book entity
attr, and then SIZE is chapter's attr, it can be handled via having several schemas (top level
entities). We can specify which fields layout to use per every request.

** There are cases when fields are clashed between BJQ tree levels in the single request.
Vast majority of them can be resolved by distingluishing  fields between entities, i.e. there
are no sigle SIZE field for book and chapter entities, but there are BOOK_SIZE and CHAPTER_SIZE,
which are different due to their nature.

** Even if it's not enough and you have an attribute which belongs two both entities at the
same time e.g. matte/glossy paper in our books sample, it seems like UI app concern. Imagine
you have a Paper Type field in search form, what do you expect from it when search by these
two joined entities? I guess the expectation is disjunction - return books which have matte
cover OR matte sheets in any chapter. So, in this case the app should buid the following query:
BJQ(books:true, PAPER:matte ) _OR_ (books:true AND PAPER:matte). But where the disjunction
hypothesis comes from, another app requires that books and their chapters both were glossy:
BJQ(books:true, PAPER:matte ) *AND* (books:true AND PAPER:matte). Also there is a room for
index time processing - take parent attr term, push down to chid. It's actually one of nuances
which I propose to defer for a while.

* I'm covering improvements for test one-by-one. Stay tuned. 

* At the end is the sweety point - syntax.

** I believe that having body of parameter (.V) fixed, and mutate values of local params {!parent
of="child_names:b"}parent:true is the way to confuse user. I checked currently present Join
queries - they don't do so. Local params are fixed by the app, and param body is mutated in
according to user request (I know what is the &localparamtrick); 

** then instead of considering how the "parent-filter-fallback" will looks like I propose
to think how the oposite form of jon will looks like (ToChildBlockJoinQuery - when you retrieve
children whose parent are passed by the filter). In this case you still need to specify parent

{!parent filter="parent:true"}child_name:b
{!child filter="parent:true"}parent_name:b
and filter itself
{!parent filter="parent:true"}

this syntax is open for misuse:
{!child filter="NOT parent:true"}parent_name:b 


The only thing I can suggest is make syntax more verbose:

{!parent which="parent:true"}child_name:b
{!child of="parent:true"}parent_name:b
{!parent which="parent:true"}


Btw, don't you think that master/detail is more appropriate terms that parent/child?

> Solr should support block joins
> -------------------------------
>                 Key: SOLR-3076
>                 URL:
>             Project: Solr
>          Issue Type: New Feature
>            Reporter: Grant Ingersoll
>         Attachments: SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, bjq-vs-filters-backward-disi.patch,
bjq-vs-filters-illegal-state.patch, parent-bjq-qparser.patch, parent-bjq-qparser.patch, solrconf-bjq-erschema-snippet.xml
> Lucene has the ability to do block joins, we should add it to Solr.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:!default.jspa
For more information on JIRA, see:


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message