Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Trivial Trivial
    • Resolution: Fixed
    • Affects Version/s: 1.4
    • Fix Version/s: 3.5, 4.0-ALPHA
    • Component/s: highlighter
    • Labels:
      None

      Description

      If hl.q parameter is set, HighlightComponent uses it rather than q.

      Use case:

      You search "PC" with highlight and facet capability:

      q=PC
      &facet=on&facet.field=maker&facet.field=something
      &hl=on&hl.fl=desc
      

      You get a lot of results with snippets (term "PC" highlighted in desc field). Then you click a link "maker:DELL(50)" to narrow the result:

      q=PC
      &facet=on&facet.field=something
      &fq=maker:DELL
      &hl=on&hl.fl=desc
      

      You'll get narrowed result with term "PC" highlighted snippets. But, sometimes I'd like to see "DELL" to be highlighted as well, because I clicked "DELL". In this case, hl.q can be used:

      q=PC
      &facet=on&facet.field=something
      &fq=maker:DELL
      &hl=on&hl.fl=desc&*hl.q=PC+maker:DELL*
      

      Note that hl.requireFieldMatch should be false (false is default) in this scenario.

      1. SOLR-1926.patch
        2 kB
        Koji Sekiguchi
      2. SOLR-1926.patch
        5 kB
        Koji Sekiguchi
      3. SOLR-1926.patch
        7 kB
        Koji Sekiguchi
      4. SOLR-1926.patch
        5 kB
        Koji Sekiguchi
      5. SOLR-1926.patch
        5 kB
        Koji Sekiguchi

        Issue Links

          Activity

          Uwe Schindler made changes -
          Status Resolved [ 5 ] Closed [ 6 ]
          Hide
          Uwe Schindler added a comment -

          Bulk close after 3.5 is released

          Show
          Uwe Schindler added a comment - Bulk close after 3.5 is released
          Koji Sekiguchi made changes -
          Status Open [ 1 ] Resolved [ 5 ]
          Resolution Fixed [ 1 ]
          Hide
          Koji Sekiguchi added a comment -

          trunk: Committed revision 1198778.
          3x: Committed revision 1198785.

          Show
          Koji Sekiguchi added a comment - trunk: Committed revision 1198778. 3x: Committed revision 1198785.
          Koji Sekiguchi made changes -
          Attachment SOLR-1926.patch [ 12502749 ]
          Hide
          Koji Sekiguchi added a comment -

          Added localParams test for hl.q parameter.

          I'll commit soon.

          Show
          Koji Sekiguchi added a comment - Added localParams test for hl.q parameter. I'll commit soon.
          Koji Sekiguchi made changes -
          Attachment SOLR-1926.patch [ 12502741 ]
          Hide
          Koji Sekiguchi added a comment -

          Just removing hl.text parameter.

          Show
          Koji Sekiguchi added a comment - Just removing hl.text parameter.
          Hide
          Koji Sekiguchi added a comment - - edited

          I misunderstood Hoss's suggestion as I read it too fast. hl.text should be multiValued and its value should be analyzed.

          would it make more sense to imagine a multivalued "hl.text" param, such that each value is passed to the analyzer for each "hl.fl" field, and the resulting terms are all highlighted (in their respective fields) ... thus bypassing the complications of extracting temrs from queries?

          would that be more useful or less useful?

          I like the idea! But as doHighlighting() method takes Query, it needs quite some time to implement it. I'd like to open a separate ticket for it.

          Show
          Koji Sekiguchi added a comment - - edited I misunderstood Hoss's suggestion as I read it too fast. hl.text should be multiValued and its value should be analyzed. would it make more sense to imagine a multivalued "hl.text" param, such that each value is passed to the analyzer for each "hl.fl" field, and the resulting terms are all highlighted (in their respective fields) ... thus bypassing the complications of extracting temrs from queries? would that be more useful or less useful? I like the idea! But as doHighlighting() method takes Query, it needs quite some time to implement it. I'd like to open a separate ticket for it.
          Koji Sekiguchi made changes -
          Attachment SOLR-1926.patch [ 12502656 ]
          Hide
          Koji Sekiguchi added a comment -

          New patch. I added a test case.

          Show
          Koji Sekiguchi added a comment - New patch. I added a test case.
          Koji Sekiguchi made changes -
          Fix Version/s 3.5 [ 12317876 ]
          Fix Version/s 4.0 [ 12314992 ]
          Koji Sekiguchi made changes -
          Assignee Koji Sekiguchi [ koji ]
          Koji Sekiguchi made changes -
          Attachment SOLR-1926.patch [ 12502647 ]
          Hide
          Koji Sekiguchi added a comment -

          This patch supports both hl.q and hl.text. The priority is:

          1. Highlighter looks if there is hl.text and if it exists, uses it. FVH doesn't look it for performance reasons.
          2. If hl.text doesn't exist, hl.q will be used.
          3. If hl.q doesn't exist, q will be used.

          localParams can be used in hl.q, and hl.text parameter accepts per-field override.

          Show
          Koji Sekiguchi added a comment - This patch supports both hl.q and hl.text. The priority is: Highlighter looks if there is hl.text and if it exists, uses it. FVH doesn't look it for performance reasons. If hl.text doesn't exist, hl.q will be used. If hl.q doesn't exist, q will be used. localParams can be used in hl.q, and hl.text parameter accepts per-field override.
          Koji Sekiguchi made changes -
          Attachment SOLR-1926.patch [ 12502645 ]
          Hide
          Koji Sekiguchi added a comment -

          The first draft patch. It implements only hl.q. I'm still working for hl.text that was suggested by Hoss.

          Show
          Koji Sekiguchi added a comment - The first draft patch. It implements only hl.q. I'm still working for hl.text that was suggested by Hoss.
          Hide
          Ukyo Virgden added a comment - - edited

          Hoss: Having a look at the highlight component I see that the Lucene highlighters require a FieldQuery. Although hl.text params makes much more sense, it seams to keep a Query object in response builder would be easier. From what I see in the code, I think set/getHighlightQuery() should not be in QParser. Anyway, setting highlight query of response builder during query preperation might do the trick.

          Show
          Ukyo Virgden added a comment - - edited Hoss: Having a look at the highlight component I see that the Lucene highlighters require a FieldQuery. Although hl.text params makes much more sense, it seams to keep a Query object in response builder would be easier. From what I see in the code, I think set/getHighlightQuery() should not be in QParser. Anyway, setting highlight query of response builder during query preperation might do the trick.
          Hide
          Ukyo Virgden added a comment -

          Hi everyone,

          What's the status of this issue? Have you found and workarounds?

          Show
          Ukyo Virgden added a comment - Hi everyone, What's the status of this issue? Have you found and workarounds?
          Koji Sekiguchi made changes -
          Field Original Value New Value
          Link This issue is related to SOLR-2632 [ SOLR-2632 ]
          Hide
          Hoss Man added a comment -

          Koji: highlighting isn't something i think about much, but i have to wonder if an alternate "highlight query" is really the best concept here (specificly the part where it's parsed by a QParser into a Query and then the terms are extracted)

          would it make more sense to imagine a multivalued "hl.text" param, such that each value is passed to the analyzer for each "hl.fl" field, and the resulting terms are all highlighted (in their respective fields) ... thus bypassing the complications of extracting temrs from queries?

          would that be more useful or less useful?

          (although: i suppose hl.requireFieldMatch wouldn't really make any sense in a situation like this ... and there'd be no way to say "highlight DELL only in the maker field")

          Hmmm... anyway, just something i wanted to toss out there in case it inspired you.

          Show
          Hoss Man added a comment - Koji: highlighting isn't something i think about much, but i have to wonder if an alternate "highlight query " is really the best concept here (specificly the part where it's parsed by a QParser into a Query and then the terms are extracted) would it make more sense to imagine a multivalued "hl.text" param, such that each value is passed to the analyzer for each "hl.fl" field, and the resulting terms are all highlighted (in their respective fields) ... thus bypassing the complications of extracting temrs from queries? would that be more useful or less useful? (although: i suppose hl.requireFieldMatch wouldn't really make any sense in a situation like this ... and there'd be no way to say "highlight DELL only in the maker field") Hmmm... anyway, just something i wanted to toss out there in case it inspired you.
          Koji Sekiguchi created issue -

            People

            • Assignee:
              Koji Sekiguchi
              Reporter:
              Koji Sekiguchi
            • Votes:
              7 Vote for this issue
              Watchers:
              6 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development