[
https://issues.apache.org/jira/browse/SOLR-3076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13207157#comment-13207157
]
Mikhail Khludnev commented on SOLR-3076:
----------------------------------------
Michael,
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 filter:
{code}
{!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
{code}
The only thing I can suggest is make syntax more verbose:
{code}
{!parent which="parent:true"}child_name:b
{!child of="parent:true"}parent_name:b
{!parent which="parent:true"}
{code}
Btw, don't you think that master/detail is more appropriate terms that
parent/child?
> Solr should support block joins
> -------------------------------
>
> Key: SOLR-3076
> URL: https://issues.apache.org/jira/browse/SOLR-3076
> 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:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
