Details

    • Type: Sub-task Sub-task
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Won't Fix
    • Affects Version/s: 1.3
    • Fix Version/s: 4.9, Trunk
    • Component/s: search
    • Labels:
      None

      Description

      The issue is dedicated to incorporate fieldcollapse's changes to the Solr's core code.

      We want to make it possible for components to specify custom Collectors in SolrIndexSearcher methods.

      1. field-collapse-core.patch
        12 kB
        Martijn van Groningen
      2. SOLR-1680.patch
        17 kB
        Noble Paul

        Activity

        Hide
        Otis Gospodnetic added a comment -

        Apparently covered by SOLR-5973.

        Show
        Otis Gospodnetic added a comment - Apparently covered by SOLR-5973 .
        Hide
        Uwe Schindler added a comment -

        Move issue to Solr 4.9.

        Show
        Uwe Schindler added a comment - Move issue to Solr 4.9.
        Hide
        Steve Rowe added a comment -

        Bulk move 4.4 issues to 4.5 and 5.0

        Show
        Steve Rowe added a comment - Bulk move 4.4 issues to 4.5 and 5.0
        Hide
        Otis Gospodnetic added a comment - - edited

        Last comment > 1 year ago.
        Patch from Martijn from 2009 and I suspect Martijn won't be working on this any more any time soon.
        And does SOLR-4465 supersede this, Joel Bernstein?

        Should this be Won't Fix?

        Show
        Otis Gospodnetic added a comment - - edited Last comment > 1 year ago. Patch from Martijn from 2009 and I suspect Martijn won't be working on this any more any time soon. And does SOLR-4465 supersede this, Joel Bernstein ? Should this be Won't Fix?
        Hide
        Tomás Fernández Löbbe added a comment -

        Why not use a Factory that could be changed from the solrconfig.xml file?

        Show
        Tomás Fernández Löbbe added a comment - Why not use a Factory that could be changed from the solrconfig.xml file?
        Hide
        Hoss Man added a comment -

        Bulk of fixVersion=3.6 -> fixVersion=4.0 for issues that have no assignee and have not been updated recently.

        email notification suppressed to prevent mass-spam
        psuedo-unique token identifying these issues: hoss20120321nofix36

        Show
        Hoss Man added a comment - Bulk of fixVersion=3.6 -> fixVersion=4.0 for issues that have no assignee and have not been updated recently. email notification suppressed to prevent mass-spam psuedo-unique token identifying these issues: hoss20120321nofix36
        Hide
        Robert Muir added a comment -

        3.4 -> 3.5

        Show
        Robert Muir added a comment - 3.4 -> 3.5
        Hide
        Robert Muir added a comment -

        Bulk move 3.2 -> 3.3

        Show
        Robert Muir added a comment - Bulk move 3.2 -> 3.3
        Hide
        Jan Kurella added a comment - - edited

        the "streamlining" could be done in simple approach?

        It seems to be quite simple according to the linked ticket.
        The codephrase

               if( timeAllowed > 0 ) {
                 collector = new TimeLimitingCollector(collector, timeAllowed);
               }
               try {
                 super.search(query, luceneFilter, collector);
               }
               catch( TimeLimitingCollector.TimeExceededException x ) {
                 log.warn( "Query: " + query + "; " + x.getMessage() );
                 qr.setPartialResults(true);
               }
        

        is spread several times over the SolrIndexSearcher.

        It should be enough to put this in a separate function and wrap the collector with any custom collector here (in one place):

          private Collector doSearch(neededParams)
               if( timeAllowed > 0 ) {
                 collector = new TimeLimitingCollector(collector, timeAllowed);
               }
               if( customCollector != null) {
                 customCollector.setInnerCollector(collector);
                 collector = customCollector
               }
               try {
                 super.search(query, luceneFilter, collector);
               }
               catch( TimeLimitingCollector.TimeExceededException x ) {
                 log.warn( "Query: " + query + "; " + x.getMessage() );
                 qr.setPartialResults(true);
               }
          }
        

        And custom collector needs to be retrieved by the whatever plugin concept.

        ??

        Show
        Jan Kurella added a comment - - edited the "streamlining" could be done in simple approach? It seems to be quite simple according to the linked ticket. The codephrase if ( timeAllowed > 0 ) { collector = new TimeLimitingCollector(collector, timeAllowed); } try { super .search(query, luceneFilter, collector); } catch ( TimeLimitingCollector.TimeExceededException x ) { log.warn( "Query: " + query + "; " + x.getMessage() ); qr.setPartialResults( true ); } is spread several times over the SolrIndexSearcher. It should be enough to put this in a separate function and wrap the collector with any custom collector here (in one place): private Collector doSearch(neededParams) if ( timeAllowed > 0 ) { collector = new TimeLimitingCollector(collector, timeAllowed); } if ( customCollector != null ) { customCollector.setInnerCollector(collector); collector = customCollector } try { super .search(query, luceneFilter, collector); } catch ( TimeLimitingCollector.TimeExceededException x ) { log.warn( "Query: " + query + "; " + x.getMessage() ); qr.setPartialResults( true ); } } And custom collector needs to be retrieved by the whatever plugin concept. ??
        Hide
        Hoss Man added a comment -

        Bulk updating 240 Solr issues to set the Fix Version to "next" per the process outlined in this email...

        http://mail-archives.apache.org/mod_mbox/lucene-dev/201005.mbox/%3Calpine.DEB.1.10.1005251052040.24672@radix.cryptio.net%3E

        Selection criteria was "Unresolved" with a Fix Version of 1.5, 1.6, 3.1, or 4.0. email notifications were suppressed.

        A unique token for finding these 240 issues in the future: hossversioncleanup20100527

        Show
        Hoss Man added a comment - Bulk updating 240 Solr issues to set the Fix Version to "next" per the process outlined in this email... http://mail-archives.apache.org/mod_mbox/lucene-dev/201005.mbox/%3Calpine.DEB.1.10.1005251052040.24672@radix.cryptio.net%3E Selection criteria was "Unresolved" with a Fix Version of 1.5, 1.6, 3.1, or 4.0. email notifications were suppressed. A unique token for finding these 240 issues in the future: hossversioncleanup20100527
        Hide
        patrick o'leary added a comment -

        We've just done something like this recently and found the simplest was was to modify
        ResponseBuilder with setCustomCollector / getCustomCollector,
        update the QueryCommand to include the custom collector.

        It gets sticky in the SolrIndexSearcher with caching, and IIRC about 4 places to call the collector, the solution works, but is not in anyway elegant.

        It would be good to see if we could refactor SolrIndexSearcher first to make it more streamlined.

        Show
        patrick o'leary added a comment - We've just done something like this recently and found the simplest was was to modify ResponseBuilder with setCustomCollector / getCustomCollector, update the QueryCommand to include the custom collector. It gets sticky in the SolrIndexSearcher with caching, and IIRC about 4 places to call the collector, the solution works, but is not in anyway elegant. It would be good to see if we could refactor SolrIndexSearcher first to make it more streamlined.
        Hide
        Shalin Shekhar Mangar added a comment -

        Why not broaden this and allow people to pass in their own collectors?

        Yes, that is the general idea, though it would be API driven than configuration. Any component should be able to pass a Collector to the various SolrIndexSearcher methods.

        Also, can you explain a bit more the use case specifically for Field Collapse?

        Field Collapsing needs to use a custom collector. Right now the collector is hard coded inside SolrIndexSearcher.

        Alternatively, given something like LUCENE-2127, we may want Solr to be able to make query time decisions about what Collector to use.

        I guess that decision should be made by QueryComponent? If so, then the ability to pass a custom Collector to SolrIndexSearcher methods should be enough.

        Show
        Shalin Shekhar Mangar added a comment - Why not broaden this and allow people to pass in their own collectors? Yes, that is the general idea, though it would be API driven than configuration. Any component should be able to pass a Collector to the various SolrIndexSearcher methods. Also, can you explain a bit more the use case specifically for Field Collapse? Field Collapsing needs to use a custom collector. Right now the collector is hard coded inside SolrIndexSearcher. Alternatively, given something like LUCENE-2127 , we may want Solr to be able to make query time decisions about what Collector to use. I guess that decision should be made by QueryComponent? If so, then the ability to pass a custom Collector to SolrIndexSearcher methods should be enough.
        Hide
        Grant Ingersoll added a comment -

        Why not broaden this and allow people to pass in their own collectors?

        Also, can you explain a bit more the use case specifically for Field Collapse?

        Alternatively, given something like LUCENE-2127, we may want Solr to be able to make query time decisions about what Collector to use.

        Show
        Grant Ingersoll added a comment - Why not broaden this and allow people to pass in their own collectors? Also, can you explain a bit more the use case specifically for Field Collapse? Alternatively, given something like LUCENE-2127 , we may want Solr to be able to make query time decisions about what Collector to use.
        Hide
        Noble Paul added a comment -

        I have added the class DocSetScoreCollector to the previous patch.

        Show
        Noble Paul added a comment - I have added the class DocSetScoreCollector to the previous patch.
        Hide
        Noble Paul added a comment -

        the class org.apache.solr.util.DocSetScoreCollector is missing in this patch

        Show
        Noble Paul added a comment - the class org.apache.solr.util.DocSetScoreCollector is missing in this patch
        Hide
        Martijn van Groningen added a comment -

        This patch contains changes to Solr's core from the last attached patch.

        Show
        Martijn van Groningen added a comment - This patch contains changes to Solr's core from the last attached patch.

          People

          • Assignee:
            Unassigned
            Reporter:
            Martijn van Groningen
          • Votes:
            5 Vote for this issue
            Watchers:
            10 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development