Uploaded image for project: 'Islandora'
  1. Islandora
  2. ISLANDORA-2181

Boolean Query on Solr Collection display generates issues with some query handler settings

    XMLWordPrintable

    Details

      Description

      Our current islandora_solr_islandora_basic_collection_backend_callable (Solr driven collection display) uses query (q) to pass a Boolean query

       $qp->buildQuery(format_string('!member_field:("info:fedora/!pid" OR "!pid") OR !collection_member_field:("info:fedora/!pid" OR "!pid")', array(
          '!member_field' => variable_get('islandora_solr_member_of_field', 'RELS_EXT_isMemberOf_uri_ms'),
          '!pid' => $collection_object->id,
          '!collection_member_field' => variable_get('islandora_solr_member_of_collection_field', 'RELS_EXT_isMemberOfCollection_uri_ms'),
        )), drupal_get_query_parameters());
      

      This set of OR query statements (which can never in a sane islandora installation) conflict with settings you can define in your solrconfig.xml file to force things like minimum match to be 100%.
      If you Solrconfig, for your default query handler has something like

      
      <requestHandler name="/select" class="solr.SearchHandler">
          <!-- default values for query parameters can be specified, these
               will be overridden by parameters in the request
            -->
          <lst name="defaults">
            <str name="echoParams">explicit</str>
            <int name="rows">10</int>
            <str name="mm">100%</str>
            <str name="q">*:*</str>
            <str name="q.op">AND</str>
            <str name="defType">edismax</str>
      

      which means, make all optional statements required and make sure they all match and always use AND, collection display breaks (0 results). Moving mm to 90% allows the display to work, sadly breaking the needed functionality of having all query words (when dealing with user input) to match.

      Solution is to move our query to a fq (filter) as we do in most of Islandora's query functionality when dealing with programmed conditions or ones that could depend on alternatives, missing alternatives. (OR)

      I think there are many other ways of breaking the q= when dealing with custom defaults at solrconfig level, so moving to fq seems a safer and proven approach.

        Attachments

          Activity

            People

            Assignee:
            dpinokrayon Diego Pino Navarro
            Reporter:
            dpinokrayon Diego Pino Navarro
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Dates

              Created:
              Updated:
              Resolved: