Based on how Drupal 8 stores dates, example:
2017-03-02T01:00:00
ES5 needs to have the format set to "date_optional_time"
https://www.elastic.co/guide/en/elasticsearch/reference/current/mapping-...
I've updated case date here and it works:
elasticsearch_connector\src\ElasticSearch\Parameters\Factory\MappingFactory.php
case 'date':
return [
'type' => 'date',
'format' => 'date_optional_time',
];
| Comment | File | Size | Author |
|---|---|---|---|
| #9 | elasticsearch_fix_date_field_format-2858873-8.patch | 754 bytes | martijn houtman |
| #6 | elasticsearch_fix_date_field_format-2858873-6.patch | 610 bytes | trebormc |
Comments
Comment #2
kmajzlik commentedThis fixes date fields - but is failing with created/updated and other timestamp properties from node/user.
Comment #3
rferguson commentedKarlos007,
Right, those are still timestamps AFAIK. This could become a dropdown selection for type just like is already there for attachment, fulltext, etc. so you could choose it to be indexed differently if you know that you're adding a date field, versus created, etc.
Comment #4
skek commentedI think the problem here is more fundamental and connected to the Search API.
The idea of Search API is to unify the date field and we are accepting different input formats, doesn't sounds correct.
What we should check is if we can make a difference between 'date' field and 'created' property for example.
We should somehow distinguish between the incoming format, something like @rferguson suggested on field level when we are configure it in Search API.
Comment #5
kmajzlik commentedJust for mention - solr does that good. Reasons why we need node.created as "date" are filter widgets, formatters etc.
Comment #6
trebormcYou were in the right direction.
Multiple formats can be specified by separating them with || as a separator. Each format will be tried in turn until a matching format is found.
The solution:
case 'date':
return [
'type' => 'date',
'format' => 'date_optional_time||epoch_second',
];
Comment #7
renrhafI confirm patch from #6 works for me. Please note you will have to purge all indexed data and launch a new index batch for this to be taken into account. Thanks !
Comment #8
renrhafComment #9
martijn houtman commentedPatch attached using strict_date_optional_time.
Comment #11
skek commentedThank you all for the work on this one. The patch has been committed.