Solr
  1. Solr
  2. SOLR-8001

Using value sources on a multi-valued field can result in an exception if no data

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 5.3
    • Fix Version/s: 5.4
    • Component/s: None
    • Labels:
      None

      Description

      SOLR-2522 Introduced the ability to reference a multi-valued field with doc values in a function query (value source) such as like this (an example using it for sorting): sort=field(myMultiValField,min) asc. In the event that the document has no values for this field, this feature behaves nicely in the aforementioned example. And it does if you reference in a 'fl' (as a DocTransformer): fl=id,myMultiValField:field(myMultiValField,min). In that case, the returned document simply doesn't have a name-value pair. But, if you sort on a more complex function that incorporates this, then you get an ArrayIndexOutOfBoundsException. Such as this:
      sort=sum(otherField,field(myMultiValField,min)) asc There may be other conditions where this same exception will be thrown; not sure.

      The root cause can either be considered one of two things (or both) I think:

      • The longVal, intVal, etc. methods on FunctionValues need to be prepared for the possibility that the document has no data, in which case it should return a default value. This means TrieLongField (& friends) are erroneous.
      • ValueSource.ValueSourceComparator could/should call exists before calling doubleVal in the various methods where it does.

      A workarround for Solr 5.3 users that should work in any situation is to wrap the field function in a def function since that forces an existence check before attempting to access the value (ie: use sort=def(field(mult_field,min),0)+asc instead of sort=field(mult_field,min)+asc)

        Issue Links

          Activity

          Hide
          David Smiley added a comment -

          I don't have a complete patch with proper assertions but I triggered the bug by editing TestMinMaxOnMultiValuedField to have a test method like so:

              assertU(adoc(sdoc("id", "0")));//nothing
              assertU(commit());
              assertQ(req("q", "*:*",
                      "sort", "sum(32,field(val_tls_dv,min)) asc"),
                  "//TODO");
          
          Show
          David Smiley added a comment - I don't have a complete patch with proper assertions but I triggered the bug by editing TestMinMaxOnMultiValuedField to have a test method like so: assertU(adoc(sdoc( "id" , "0" ))); //nothing assertU(commit()); assertQ(req( "q" , "*:*" , "sort" , "sum(32,field(val_tls_dv,min)) asc" ), " //TODO" );
          Hide
          Hoss Man added a comment -

          david: thanks for following up ... in this context your comments in SOLR-2522 totally make sense to me now.

          i'll take care of fleshing out a patch with comprehensive tests and fixes (including your note about optimizing away the extra ord call)

          Show
          Hoss Man added a comment - david: thanks for following up ... in this context your comments in SOLR-2522 totally make sense to me now. i'll take care of fleshing out a patch with comprehensive tests and fixes (including your note about optimizing away the extra ord call)
          Hide
          Hoss Man added a comment -

          David: please check out the attached patch and let me know if this is what you had in mind.

          NOTE: I discovered that the sort order when using this function on docs w/o values is inconsistent with the order when using a single valued field (containing the same effictive value) and filed that as a seperate bug since i can't think of a clear solution at the moment: SOLR-8005

          Show
          Hoss Man added a comment - David: please check out the attached patch and let me know if this is what you had in mind. NOTE: I discovered that the sort order when using this function on docs w/o values is inconsistent with the order when using a single valued field (containing the same effictive value) and filed that as a seperate bug since i can't think of a clear solution at the moment: SOLR-8005
          Hide
          David Smiley added a comment -

          +1 Nice work Hoss Man. The patch looks good.

          Show
          David Smiley added a comment - +1 Nice work Hoss Man . The patch looks good.
          Hide
          ASF subversion and git services added a comment -

          Commit 1701081 from hossman@apache.org in branch 'dev/trunk'
          [ https://svn.apache.org/r1701081 ]

          SOLR-8001: Fixed bugs in field(foo,min) and field(foo,max) when some docs have no values

          Show
          ASF subversion and git services added a comment - Commit 1701081 from hossman@apache.org in branch 'dev/trunk' [ https://svn.apache.org/r1701081 ] SOLR-8001 : Fixed bugs in field(foo,min) and field(foo,max) when some docs have no values
          Hide
          ASF subversion and git services added a comment -

          Commit 1701090 from hossman@apache.org in branch 'dev/branches/branch_5x'
          [ https://svn.apache.org/r1701090 ]

          SOLR-8001: Fixed bugs in field(foo,min) and field(foo,max) when some docs have no values (merge r1701081)

          Show
          ASF subversion and git services added a comment - Commit 1701090 from hossman@apache.org in branch 'dev/branches/branch_5x' [ https://svn.apache.org/r1701090 ] SOLR-8001 : Fixed bugs in field(foo,min) and field(foo,max) when some docs have no values (merge r1701081)
          Hide
          Hoss Man added a comment -

          thanks david.

          Show
          Hoss Man added a comment - thanks david.

            People

            • Assignee:
              Hoss Man
              Reporter:
              David Smiley
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development