Problem/Motivation

Critical because this is a regression to the previous version for me, lets discuss if you disagree.

I have something like this in a search api solr query alter hook:

    $backend = $query->getIndex()->getServerInstance()->getBackend();
    if ($backend instanceof SearchApiSolrBackend) {
      $field_names = $backend->getSolrFieldNames($query->getIndex(), TRUE);
      if (!isset($field_names['my_date_field'])) {
        return;
      }
      $solr = $backend->getSolr();
      $customizer = $solr->getPlugin('customizerequest');
      $customizer->createCustomization('bf')
        ->setType('param')
        ->setName('boost')
        ->setValue('recip(ms(NOW/DAY,' . $field_names['my_date_field'] . "),3.16e-11,$a,$b)");
    }
  }

But getSolr() doesn't exist anymore and that is now a protected, non-accessible property on the connector.

I guess I could write my own connector plugin and do that logic there, But that seems overkill to me and the problem with such a pattern is always that you can only have one connector, you might have more than one use case for such an alter hook implementation.

What's the point of the alter hook if you can't alter the solr query anymore?

Related, will open an issue for this as well: setMoreLikeThis() seems completely broken right now, as it still acesses ->solr, just like my code, found that when researching this. That's also a regression IMHO.

Proposed resolution

a) Make customizeRequest() public and part of the connector API.
b) Add a getSolr() public method to the connector API
c) Pass the Solr instance directly to the alter hook (which would imply that you need to move the call into the connector plugin)

Remaining tasks

User interface changes

API changes

Data model changes

Comments

Berdir created an issue. See original summary.

mkalkbrenner’s picture

mkalkbrenner
Primary language German
Location 🇩🇪
commented

From my point of view the main purpose of the customizerequest plugin is to modify the HTTP headers which is connector specific. There're two different ways to add GET params to the final Solr query string, depending on where you are in the call stack:

function hook_search_api_query_alter(\Drupal\search_api\Query\QueryInterface &$query) {
  ...
  $query->setOption('solr_param_boost', 'recip(ms(NOW/DAY,' . $field_names['my_date_field'] . "),3.16e-11,$a,$b)");
}

or

function hook_search_api_solr_query_alter(\Solarium\QueryType\Select\Query\Query $solarium_query, \Drupal\search_api\Query\QueryInterface $query) {
  ...
  $solarium_query->addParam('boost', 'recip(ms(NOW/DAY,' . $field_names['my_date_field'] . "),3.16e-11,$a,$b)");
}

Nevertheless, I'm open to extend the API in any way. I would prefer option b) or c). But I still wonder if it is really a good choice or if it isn't better to have use use-cases that could not be resolved as mentioned above to be encapsulated in their own connector implementation.
What's your opinion?

berdir’s picture

berdir
Primary language German
Location Switzerland
commented

Thanks for the feedback. That works for me.

Only question IMHO is then what to do with #2823540: SearchApiSolrBackend::setMoreLikeThis() accesses non-existing solr property, if we need something from here or if we'll move more of that logic into the connector.

If we don't need it for that issue, feel free to close this as a support request :)

mkalkbrenner’s picture

mkalkbrenner
Primary language German
Location 🇩🇪
commented
Category: Bug report » Support request
Priority: Critical » Normal
Status: Active » Fixed

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.