lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael McCandless (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (SOLR-3076) Solr should support block joins
Date Mon, 26 Mar 2012 10:05:25 GMT

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

Michael McCandless commented on SOLR-3076:
------------------------------------------

{quote}
2. Do you agree with overall approach to deliver straightforward QP with explicit joining
syntax? Or you object and insist on entity-relationship-schema approach?

3. What's is the level of uncertainty you have about the current QP syntax? What's your main
concern and what's the way to improve it?
{quote}

Well, stepping back, my concern is still that I don't think there
should be any QP syntax to express block joins.  These are joins
"determined" at indexing time, and compiled into the index, and so the
only remaining query-time freedom is which fields you want to search
against (something QP can already understand, ie field:text syntax).
>From that fields list the required joins are implied.

I can't imagine users learning/typing the sort of syntax we are
discussing here.

It's true there are exceptional cases (Hoss's "size" field that's on
both parent and child docs), but, that's the exception not the rule; I
don't think we should design things (APIs, QP syntax) around exceptional
cases.  And, I think such an exception should be
handled by some sort of field aliasing ("book_page_count" vs
"chapter_page_count").

For query-time join, which is fully flexible, I agree the QP must (and
already does) include join syntax, ie be more like SQL, where you can
express arbitrary on-the-fly joins.

But, at the same time, the 'users' of Solr's QP syntax may not be the
"end" user, ie, the app's front end may very well construct these
complex join expressions.... and so it's really the developers of that
search app writing these join queries.  So perhaps it's fine to add
crazy-expert syntax that end users would rarely use but search app
developers might...?

All this being said, I defer to Hoss (and other committers more
experienced w/ Solr QP issues) here... if they all feel this added QP
syntax makes sense then let's do it!

                
> 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, SOLR-3076.patch,
SOLR-3076.patch, bjq-vs-filters-backward-disi.patch, bjq-vs-filters-illegal-state.patch, child-bjqparser.patch,
parent-bjq-qparser.patch, parent-bjq-qparser.patch, solrconf-bjq-erschema-snippet.xml, tochild-bjq-filtered-search-fix.patch
>
>
> 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message