Add possibility to boost fields in MLT queries

Huh, just realized we neglected to actually properly define the search_api_mlt feature anywhere in Drupal 8!
However, if we do that, I guess we can just add a third parameter, field boosts (or similar) to the search_api_mlt option. It should probably be an associative array, mapping field names to their boosts. And backends should be explicitly allowed to ignore them (which we couldn’t really prevent anyways, of course – but just to do things properly, since we’re changing an existing feature).

Once it’s in the defintion, you can go to the Solr module and provide a patch there for supporting the new option.

I’m attaching a patch with a proposed feature definition. Please review!

+++ b/README.txt
@@ -106,6 +106,32 @@ module's issue regarding potential module-specific changes to that policy [7].
+  - fields: A simple array of fields which should be used for determining
+    similarity. Backends can choose to ignore this field.
+  - "field boosts": (optional) An associative array mapping fields to a numeric
+    "boost" value that determines how important they should be considered when
+    determining similarity. Backends can choose to ignore this field.

For the "field boosts"-key, we explictly say that it is optional. For the fields key we don't but they both seem to be optional.

It would be nice to mark them in the same way?

Otherwise I think this is sufficient documentation about this.

I agree with Thomas' suggestion. But the UI to set the fields and their boosts should be added to Search API, just like for the other field boosts.

For the "field boosts"-key, we explictly say that it is optional. For the fields key we don't but they both seem to be optional.

It would be nice to mark them in the same way?

Why do you think fields is optional, too?
Looking at \Drupal\search_api\Plugin\views\argument\SearchApiMoreLikeThis::query(), this is always set, and \Drupal\search_api_solr\Plugin\search_api\backend\SearchApiSolrBackend::getMoreLikeThisQuery() also expects it to always be present.
So, I wouldn’t say it’s optional. It might have made sense to make it optional, but since it’s already used otherwise (and would, I think, add additional work for implementing backends), I don’t think we should change that.

The optional part is whether the backend actually looks at the setting, but it should always be set by modules using the feature, I’d say. (We could also remove that last sentence, basically saying backends need to take this into account, but I don’t see a point in that.)

I agree with Thomas' suggestion. But the UI to set the fields and their boosts should be added to Search API, just like for the other field boosts.

I think a UI for this would be overkill at this point. Using this in custom search code, or in an alter hook, makes sense, but for the UI I’d say this is too much of a niche feature. If enough people speak up for it, we can still add a UI in a follow-up (and of course it should be in the Search API then), but I doubt that that will happen.

Using this in custom search code, or in an alter hook, makes sense, but for the UI I’d say this is too much of a niche feature.

I just want to ensure that search_api_solr isn't responsible to alter the existing UI to add this feature. In case a UI is required it would be easier to implement it in search_api itself. If we don't offer a UI at all, I'm fine with it.

Why do you think fields is optional, too?

I think that was because it says: Backends can choose to ignore this field..

I think that was because it says: Backends can choose to ignore this field..

Ah, yes, that’s what I figured then. But it’s optional in the other direction, so to speak, in that case. It still has to be provided.

But so this is RTBC in both your opinions?

Yep!

Excellent, thanks!
Committed.
Thanks again for weighing in, everyone!