You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Mikhail Khludnev (JIRA)" <ji...@apache.org> on 2013/08/11 21:23:50 UTC

[jira] [Comment Edited] (SOLR-3076) Solr(Cloud) should support block joins

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

Mikhail Khludnev edited comment on SOLR-3076 at 8/11/13 7:22 PM:
-----------------------------------------------------------------

bq. like when someone deletes a parent doc but not it's children 

I've thought it so. However, there is an argument provided by one of my colleagues and the brightest engineer ever (Nina G) - such courtesy works until merge happens, and after merge/expunge deletes it's a pain. So, beside it's inconsistent, I even thought it wont be passed by random tests.   

bq. See LUCENE-5092, it looks like something like that has been rejected.
that approach has performance implication, but I propose nothing more just API massaging without any real implementation changes/extending: let BJQ work with something, which is either CachingWrapperFilter or BitDocSet.getTopFilter().

bq.  If we're happy with those, I think we should commit at this point -  

I got your point. It makes sense. We just need to raise followup issue - unify BJQs across Lucene and Solr, and ideally address it before the next release. Otherwise, it's just a way to upset a user - if someone happy with BJQ in Lucene, it should be clear that with this parser he goes to another BJQs. As an alternative intermediate measure, don't you think it's more honest to store CachingWrapperFilter in Solr's filtercache via ugly hack, for sure. Then, follow up and address it soon.  

bq. this issue has been open for far too long)
but who really cares?  

Thanks
                
      was (Author: mkhludnev):
    bq. like when someone deletes a parent doc but not it's children 

I've thought it so. However, there is an argument provided by one of my colleagues and the brightest engineers ever (Nina G): such courtesy works until merge happens, and after merge/expunge deletes it's a pain. So, beside it's inconsistent, I even thought it wont be passed by random tests.   

bq. See LUCENE-5092, it looks like something like that has been rejected.
that approach has performance implication, but I propose nothing more just API massaging without any real implementation changes/extending: let BJQ work with something, with is either CachingWrapperFilter or BitDocSet.getTopFilter().

bq.  If we're happy with those, I think we should commit at this point - this issue has been open for far too long) not found.

I got your point. It makes sense. We just need to raise followup issue - unify BJQs across Lucene and Solr, and ideally address it before the next release. Otherwise, it's just a way to upset a user - if someone happy with BJQ in Lucene, it should be clear that with this parser he goes to another BJQs. As an alternative intermediate measure, don't you think it's more honest to store CachingWrapperFilter in Solr's filtercache via ugly hack, for sure. Then, follow up and address it soon.  

Thanks
                  
> Solr(Cloud) 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
>            Assignee: Yonik Seeley
>             Fix For: 4.5, 5.0
>
>         Attachments: 27M-singlesegment-histogram.png, 27M-singlesegment.png, bjq-vs-filters-backward-disi.patch, bjq-vs-filters-illegal-state.patch, child-bjqparser.patch, dih-3076.patch, dih-config.xml, parent-bjq-qparser.patch, parent-bjq-qparser.patch, Screen Shot 2012-07-17 at 1.12.11 AM.png, SOLR-3076-childDocs.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-7036-childDocs-solr-fork-trunk-patched, solrconf-bjq-erschema-snippet.xml, solrconfig.xml.patch, 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
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