Search API integration

Thanks for reporting, the mismatch between definition and value is certainly wrong. This would be a breaking change though, because currently, you can use the occurrence property values as DateTime objects. Do you know if SearchApi is able to work with DateTime objects directly (and is there a data definition type in Drupal for this)?

If not, I'll commit your patch once I do a new release and at the same time add the DateTime object as start_date and end_date properties (as with core datetime_range field item properties).

Where to start with integrating this module with search api and solr.

When the occurrences values field is added to the index if the field carnality is not set to unlimited solr won't index the values because solr create a time single field(ts) not a time multi field(tm). We should be able to modify it using a hook_search_api_solr_field_mapping_alter.

2018-02-01 21:09:35.306 ERROR (qtp947679291-14) [   x:drupal] o.a.s.h.RequestHandlerBase org.apache.solr.common.SolrException: ERROR: [doc=ts3v6z-content-entity:node/6:en] multiple values encountered for non multiValued field ds_value: [2018-02-01T00:00:00Z, 2018-02-03T00:00:00Z, 2018-02-05T00:00:00Z, 2018-02-07T00:00:00Z, 2018-02-09T00:00:00Z, 2018-02-11T00:00:00Z, 2018-02-13T00:00:00Z, 2018-02-15T00:00:00Z, 2018-02-17T00:00:00Z, 2018-02-19T00:00:00Z, 2018-02-21T00:00:00Z, 2018-02-23T00:00:00Z, 2018-02-25T00:00:00Z, 2018-02-27T00:00:00Z]

After I changed the carnality on the field I did succeed in indexing the node with the multi value field. Then I tried to list the values in a views similar to ( https://www.drupal.org/project/date_recur/issues/2846298 → ). I didn't have any luck, the occurring fields were coming up blank. I was able to list the start date or use the rendered entity display to list the re occurring dates for this event.

Thinking more about integration with search api when indexing the content with a recur date. Would it make sense to fake/re write the data in the recur date field with the occurrences dates and have search api index the field as just a simple multi value date field.
Another possibility would be to have another field added to the content with just the list of occurrences and have search api index those.

It would be good to get some feedback from anyone. This will be a very crucial module since Core have no plans on implementing a re occurring date field.

More information I just found that this patch is correct in the application but when applied and used with views the \DateTime::ISO8601 is not understood and does break. View tries to format the date but since the ISO8601 is a formatted date already it generates an error.

I changed it to just use a unix timestamp and then views was able to format the dates.

[Fri Feb 02 15:19:15.351680 2018] [:error] [pid 14863] [client 99.240.70.181:60556] Uncaught PHP Exception InvalidArgumentException: "The timestamp must be numeric." at /var/www/html/dev/3-date-support/drupal/core/lib/Drupal/Component/Datetime/DateTimePlus.php line 199, referer: https://3-date-support.cmh.cflabs.ca/en/admin/structure/views/view/solr_instance

So I'm having a think about Search API and Date Recur.

I'm thinking maybe, just as views gets a join on the table, Search API gets maybe a processor, such that the occurrences can either:

• It's horrid with the Content Entity Datasource item ID,
• or it can be indexed as if it's a multiple field.

Does that make sense?

With the latest Search API the :occurrences sub-field can no longer be indexed at all as it is of type 'any'.

The following fields cannot be indexed since there is no type mapping for them:

    Date » Computed start date (type "any")
    Date » Computed end date (type "any")
    Date » Occurrences (type "any")

The computed property on the field does seem to be the best way of exposing this data to Search API. The only other practical way would be to add a General Property (search api plugin, like aggregated field), that would get and add this information.

The data in the property would fit into the field:date_range type. I'm not sure if that's practical however. If it is it would then automatically be recognised, and the :value and :end_value used.

Alternatively Drupal\date_recur\DateRange could be replaced by Typed Data for which Search API support can be added.

Both options would require some API level changes, as :occurrences and the DateRange class are used extensively. As such it would be interesting to know any opinions from the maintainers.

Hi @ekes,

Though I dont have a use case myself for Recurring Dates Field + Search [API], I'm interested in facilitating what needs to be done here.

• First of course, defining what a good use case for integration is.
• If something out of the box with DR is breaking search API, per original issue summary, even without explicit integration, lets try to prevent breakage.
• Working on patches for the project.
• Tests for the project
• Community agreement on the integration

First of course, defining what a good use case for integration is.

I hope mr.baileys and others on the issue can add their cases. Mine: events, with repeating dates, go into a search index, where people can then filter (facets) by (amongst other things) events occurring between date X and date Y, or in the month of Z etc.

If something out of the box with DR is breaking search API, per original issue summary, even without explicit integration, lets try to prevent breakage.

I don't think you can make it break any more. I'm not sure how the property was declared in 1.x, or if this has changed. But as of now with the latest version of Search API, it won't add occurrences with the Data Type 'any' to the index. So you can't start to try and index the occurrences, to make it break.

Which is where changing the Data Type of the :occurrences computed sub-field, or possibly duplicating it - if changing the API is too disruptive - seems the best course. First question for patching: Would the disruptive change, altering from 'any' to something eles be fine? Then it's writing something to change / add a Data Type that is either recognised already by Search API, or that can have a plugin added so that it is recognised. As example field:date_range contains the exact same fields, but has a data definition, and it is well (very well in the case of solr) supported already.

Sorry that was stored in my browser it seems.

I believe the issue reported in the original IS is being fixed in #2921280: Error on adding a Date range field to the search API → .

cause the entity to be indexed for each occurrence (have to investigate how the search api id would work) It's horrid with the Content Entity Datasource item ID,

I built this feature, which can be found here: https://www.drupal.org/sandbox/sam/3200275 →

or it can be indexed as if it's a multiple field.

Rolling in the above feature would not prevent this feature from also being written. Both would need to be configured and added to SAPI indexes, so the user could decide how they want the integration to work.

I've used code from https://www.drupal.org/sandbox/sam/3200275 → in the experimental https://drupal.org/project/date_occur More specifically in https://git.drupalcode.org/project/date_occur/-/tree/0.1.x/date_occur_sapi which now uses the Date Occurrence DataType supplied by https://git.drupalcode.org/project/date_occur/-/tree/0.1.x/date_occur All still wants more rounding off, it will be developed and tested further.

There's also decorated version in https://git.drupalcode.org/project/date_occur/-/tree/0.1.x/date_occur_ui which allows for swapping the entity, and having a parent entity, for overriden occurrence instances -- this is all pulled together in the example configuration https://git.drupalcode.org/project/date_occur/-/tree/0.1.x/date_occur_ex...