Solr
  1. Solr
  2. SOLR-4318

NullPointerException encountered when /select query on solr.TextField.

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 4.0
    • Fix Version/s: 4.3, 5.0
    • Component/s: Build
    • Labels:

      Description

      I have two fields, one is title and the other is description in my Solr schema like -
      Type - <fieldType name="text" class="solr.TextField" positionIncrementGap="100"/>

      Declaration - <field name="description" type="text" indexed="true" stored="true"/>
      without any tokenizer or filter.

      On querying /select?q=description:myText it works. However when I add a '*' it fails.

      Failure scenario -
      /select?q=description:*
      /select?q=description:myText*
      .. etc

      solrconfig.xml -

      <requestHandler name="/select" class="solr.SearchHandler">
      <lst name="defaults">
      <str name="echoParams">explicit</str>
      <int name="rows">10</int>
      <str name="df">title</str>
      </lst>
      </requestHandler>

      1. SOLR-4138.patch
        4 kB
        Erick Erickson
      2. SOLR-4318.patch
        1 kB
        Erick Erickson

        Activity

        Hide
        Uwe Schindler added a comment -

        Closed after release.

        Show
        Uwe Schindler added a comment - Closed after release.
        Hide
        Commit Tag Bot added a comment -

        [branch_4x commit] Erick Erickson
        http://svn.apache.org/viewvc?view=revision&revision=1457077

        SOLR-4318 NPE when doing a wildcard query on a TextField with the default analysis chain

        Show
        Commit Tag Bot added a comment - [branch_4x commit] Erick Erickson http://svn.apache.org/viewvc?view=revision&revision=1457077 SOLR-4318 NPE when doing a wildcard query on a TextField with the default analysis chain
        Hide
        Erick Erickson added a comment -

        Trunk r: 1457032
        4x r: 1457077

        Thanks for reporting this Junaid!

        Show
        Erick Erickson added a comment - Trunk r: 1457032 4x r: 1457077 Thanks for reporting this Junaid!
        Hide
        Erick Erickson added a comment -

        Patch with CHANGES entry as well as code.

        Show
        Erick Erickson added a comment - Patch with CHANGES entry as well as code.
        Hide
        Commit Tag Bot added a comment -

        [trunk commit] Erick Erickson
        http://svn.apache.org/viewvc?view=revision&revision=1457032

        SOLR-4318 NPE when doing a wildcard query on a TextField with the default analysis chain

        Show
        Commit Tag Bot added a comment - [trunk commit] Erick Erickson http://svn.apache.org/viewvc?view=revision&revision=1457032 SOLR-4318 NPE when doing a wildcard query on a TextField with the default analysis chain
        Hide
        Erick Erickson added a comment - - edited

        Actually, on a second look I think the original patch is the right thing to do. There is actually a default tokenizer assigned to a TextField, admittedly it is rudimentary, but it's still defined. So my original statement was entirely wrong, a TextField type with no analysis chain is perfectly correct, it was entirely a problem with the MultiTermAware code. Fixing it with the original patch is fine. I'll add a test too.

        Show
        Erick Erickson added a comment - - edited Actually, on a second look I think the original patch is the right thing to do. There is actually a default tokenizer assigned to a TextField, admittedly it is rudimentary, but it's still defined. So my original statement was entirely wrong, a TextField type with no analysis chain is perfectly correct, it was entirely a problem with the MultiTermAware code. Fixing it with the original patch is fine. I'll add a test too.
        Hide
        Junaid Surve added a comment - - edited

        Erick I'd say the 1.1 is better, enforces use of Tokenizer when type is Text. Also a line in the docs letting everyone know that Text fields need to have a Tokenizer.
        - for "I'm sure Junaid's next question would be that results weren't as expected".

        Show
        Junaid Surve added a comment - - edited Erick I'd say the 1.1 is better, enforces use of Tokenizer when type is Text. Also a line in the docs letting everyone know that Text fields need to have a Tokenizer. - for "I'm sure Junaid's next question would be that results weren't as expected".
        Hide
        Erick Erickson added a comment - - edited

        Hmmm, this is an invalid field definition, you have to have at least one tokenizer or your field doesn't do anything.

        I can mask the error with a couple of trivial changes (see patch attached) but I don't think that's really a good fix. It seems we should (in order of my preference, either of my two <1>'s work for me)

        1> fail hard at startup and force a valid fieldType definition before continuing.
        1> default to WhitespaceTokenizer if no analysis chain defined. I can make get onboard with this being reasonable behavior
        2> do nothing. I think this is a bad solution, violates the "fail early" policy, doesn't fail until someone happens to do a wildcard
        3> put in a trivial fix (two places have to test for null like in the patch). I don't like this either, I'm sure Junaid's next question would be that results weren't as expected, everyone wastes time then.

        Anyone want to weigh in?

        Show
        Erick Erickson added a comment - - edited Hmmm, this is an invalid field definition, you have to have at least one tokenizer or your field doesn't do anything. I can mask the error with a couple of trivial changes (see patch attached) but I don't think that's really a good fix. It seems we should (in order of my preference, either of my two <1>'s work for me) 1> fail hard at startup and force a valid fieldType definition before continuing. 1> default to WhitespaceTokenizer if no analysis chain defined. I can make get onboard with this being reasonable behavior 2> do nothing. I think this is a bad solution, violates the "fail early" policy, doesn't fail until someone happens to do a wildcard 3> put in a trivial fix (two places have to test for null like in the patch). I don't like this either, I'm sure Junaid's next question would be that results weren't as expected, everyone wastes time then. Anyone want to weigh in?

          People

          • Assignee:
            Erick Erickson
            Reporter:
            Junaid Surve
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development