After upgrading Search API module from 8.x-1.15 to 8.x-1.16 - on my site becomes broken indexing of Spatial (rpt type, or location) field types based on search_api_location module (this module version is not changed) - they becomes empty.

The problem is with Geolocation field type, Geofield field types works well

How to repoduce:
1. Install search_api=8.x-1.15, search_api_location= 8.x-1.0-alpha1, search_api_solr=3.8.0, geolocation=8.x-3.2
2. Create some entity with search_api_location field type, fill any coordinates in it, eg machine name field_location with value -73.138260 40.792240.
3. Make Search API index of this entity with rpt (Spatial Recursive Prefix Tree) type of index for search_api_location field.
4. Lookup at indexed data, you will see that this field is indexed normally, index contains field field_location with value [-73.138260, 40.792240].
5. Update search_api from 8.x-1.15 to 8.x-1.16 and reindex this entity, you will see that field_location field disappear from index.

Downgrading to 8.x-1.15 solve this issue.

Comments

Murz created an issue. See original summary.

murz’s picture

The source of problem is in this part of code: search_api/src/Utility/FieldsHelper.php - function extractFieldValues()

    // Process complex data types.
    if ($definition instanceof ComplexDataDefinitionInterface) {
      $main_property_name = $definition->getMainPropertyName();
      $data_properties = $data->getProperties();
      if (isset($data_properties[$main_property_name])) {
        return $this->extractFieldValues($data_properties[$main_property_name]);
      }
      return [];
    }

geolocation field type provide 'value' as $main_property_name, but in $values - 'value' key is missing, here is $values contents:

values:array(3)
  lat:"-73.138260"
  lng:"40.792240"
  data:null

Previous version of this code from 1.15 is:

    $value = $data->getValue();
    $definition = $data->getDataDefinition();
    if ($definition instanceof ComplexDataDefinitionInterface) {
      $property = $definition->getMainPropertyName();
      return isset($value[$property]) ? [$value[$property]] : [];
    }
    if (is_array($value)) {
      return array_values($value);
    }
    return [$value];

that works well with this field type.

murz’s picture

Status: Active » Needs review
StatusFileSize
new589 bytes

Quick solution is replace:

      return [];

with old logic, like this:

      $value = $data->getValue();
      return isset($value[$main_property_name]) ? [$value[$main_property_name]] : [];

because only with getValue(); field returns 'value' key, that act as $main_property_name, because it is not stored in database, but calculated dynamically.

After proposed changes - all becomes work right. Patch is attached

Can anybody lookup - is this right way to fix described issue?

murz’s picture

Issue summary: View changes
murz’s picture

StatusFileSize
new668 bytes

I investigate deeper and seems found better solution: for geolocation field type the value property is computed, but function getProperties($include_computed = FALSE) don't include computed properties by default.

So simply enabling $include_computed solve the issue too, so I change line:

      $data_properties = $data->getProperties();

to

      $data_properties = $data->getProperties(true);

Patch is attached.

murz’s picture

Title: Upgrade Search API from 8.x-1.15 to 8.x-1.16 breaks Spatial (rpt location) field type indexing » Upgrade Search API from 8.x-1.15 to 8.x-1.16 breaks Spatial (rpt location) field type indexing and seems other field types with computed value
murz’s picture

Title: Upgrade Search API from 8.x-1.15 to 8.x-1.16 breaks Spatial (rpt location) field type indexing and seems other field types with computed value » Upgrade Search API from 8.x-1.15 to 8.x-1.16 breaks Geolocation field type indexing and seems other field types with computed value
Issue summary: View changes
drunken monkey’s picture

Status: Needs review » Fixed

Thanks a lot for reporting this problem!
You’re right, your latest solution in #5 looks really good. It also shouldn’t really break anything – worst case, it will slow down some sites a bit if they contain complex computed properties. (Don’t know if those are very common, though – I don’t know of any.)
The only issue I have with the patch that, in Drupal, TRUE should always be uppercase. (See also the “coding standards message” in the test bot results.)

Otherwise, I think this looks great, so even at the risk of getting complaints about decreased performance (though I hope not): committed.
Thanks again!

  • drunken monkey committed f1ea464 on 8.x-1.x authored by Murz
    Issue #3157397 by Murz, drunken monkey: Fixed indexing of complex...

Status: Fixed » Closed (fixed)

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

hudri’s picture

Patch #5 worked for me with Search API v1.17 and Geolocation v3.2