Add operators for (NOT) IN and (NOT) BETWEEN

Ok, lets start with the tests to see which direction this takes ...

There is a bunch of places in the patch where you change array to [], Search API only uses the long array notation. If you can revert that change it'll be easier to see what changes are actually needed here.

back to NW.

Ok, changed short array syntax back to long arrays.

I think this looks good and I like that there's additional testcoverage. I did find some things that can be improved.

1. +++ b/src/Plugin/search_api/processor/Tokenizer.php
   @@ -175,19 +175,36 @@ class Tokenizer extends FieldsProcessorPluginBase {
   -  protected function processFieldValue(&$value, &$type) {
   +  public function processFieldValue(&$value, &$type) {
   

   Why is this now a public method?

2. +++ b/src/Processor/FieldsProcessorPluginBase.php
   @@ -292,11 +292,11 @@ abstract class FieldsProcessorPluginBase extends ProcessorPluginBase {
   +   * @param mixed $value
   +   *   The string value or an array of string values to preprocess, as a
   +   *   reference. Can be manipulated directly, nothing has to be returned.
   +   *   The values can either be left a string, or changed into an array of
   +   *   tokens. A token is an associative array containing:
   

   Let's make this more explicit, it's string|string[].

3. +++ b/src/Processor/FieldsProcessorPluginBase.php
   @@ -348,10 +348,11 @@ abstract class FieldsProcessorPluginBase extends ProcessorPluginBase {
   +   * @param mixed $value
   

   Again, string|string[]

4. +++ b/src/Plugin/search_api/processor/HtmlFilter.php
   @@ -136,6 +136,21 @@ class HtmlFilter extends FieldsProcessorPluginBase {
   +    if (!is_array($value)) {
   +      $this->_processFieldValue($value, $type);
   +      return;
   +    }
   +    foreach ($value as &$field_value) {
   +      $this->_processFieldValue($field_value, $type);
   +    }
   

   This is the only method where an early return is added, let's put the foreach in an else statement; like the other processors

Uh, I forgot to change the function visibility back after some debugging attempts ...

Added your changes.

I think this looks great, let's see what @drunken_monkey thinks about this patch. The added testcases are awesome!

Uhm, but it's not complete, yet :)
I will have look into search_api_db to see, what has to be done there.

Alright, setting back to NW.

Next round.
I updated the tests for search_api_db and think, it's complete now. Please note that "NOT BETWEEN" doesn't seem supported by Drupal core itself yet. I've created an issue to see, if we could add it (#2686483: Add support for database condition operator "NOT BETWEEN").

Additional question: do we want to prefix the assertion messages (i.e. within \Kernel\BackendTest) with at least the function name? Because the test uses only one test function (testFramework()) it is very hard to debug, which specific test fails.

Forgot the interdiff.

Doesn't it report the line number anyways?

Unfortunately it always prints line 93 (function stub of testFramework()).

Hello,

I've re created the patch. It applies now.
Here it goes.

Sorry, here goes again.

I think it looks great code-wise, pretty sure that the views part can be a follow-up.

I now added the support for BETWEEN to the Solr backend as well.

But I'm against "NOT BETWEEN" because the programmer who requires that should be able to do the required conversion by himself using the existing operators, for example BETWEEN a,b OR BETWEEN c,d instead of
BETWEEN a,d AND NOT BETWEEN b,c.

If you really like, you can add NOT BETWEEN.
For sure we could handle this in the solr backend as well, even if the query API isn't intuitive for people coming from Solr. I feels more like SQL. Personally I don't like that direction, but that's just me ;-)

I run into a problem with the IN operator using the database backend:

1) Add ViewsData for a search_api_field to InOperator:

function mymodule_views_data_alter(array &$data) {
  $tables = array(
    'search_api_entity_node',
    'search_api_index_site_search',
    'search_api_datasource_site_search_entity_node',
    'node__field_afdeling',
  );
  foreach ($tables as $table) {
    $data[$table]['field_afdeling']['filter']['id'] = 'in_operator';
    $data[$table]['field_afdeling']['filter']['options callback'] = 'mymodule_afdelingen_options';
    $data[$table]['field_afdeling']['filter']['allow empty'] = TRUE;
  }
}

2. Now expose the field in views and it's a select (or multiselect).

3. The error I get is: Unknown operator 'in' used in search query condition.

The BackendPluginBase::validateOperator validates on 'IN' and not on 'in'.