BUGFIX: Version 2.x of elasticsearch does neither need nor accept index_name in fields mapping

[Torsten85]

Using an annotation like this:

    /**
     * @var string
     * @ORM\Column(nullable=true)
     * @ElasticSearch\Indexable
     * @ElasticSearch\Mapping(fields={@ElasticSearch\Mapping(index_name="raw", type="string", analyzer="case_insensitive_sort")})
     */
    protected $title;

with version 2.x of elasticsearch throws the error:

{
  "error": {
    "root_cause": [
      {
        "type": "mapper_parsing_exception",
        "reason": "Mapping definition for [fields] has unsupported parameters: [index_name: raw]"
      }
    ],
    "type": "mapper_parsing_exception ",
    "reason": "Mapping definition for [fields] has unsupported parameters: [index_name: raw]"},
    "status": 400
  }

[johannessteu]

This configuration option should be documented

[Torsten85]

I've added the relevant part to the README.md

[johannessteu]

Would the default version 1.x break most installations? Not sure if we should set 1.x or 2.x to default?! For sure this option is nowhere else used atm but could be in the future

[Torsten85]

I think it would be better to set the default value to 1.x. So the package behaviour won't change out of the box and you have to intentionally change the setting to get a different result.

[patricweihmayer]

For us this works well. We run our application on Neow/Flow 4.0.5 with Elasticsearch 5.4.1. We´re looking forward to find this request merged to receive it with the next release - good job, thanks.

[kdambekalns]

@patricweihmayer You run Elasticsearch 5.4.1? With which version of the CR adaptor? 😯

[dfeyer]

Based on the documentation elastic/elasticsearch#6677 index_name is deprecated in favor of copy_to, so maybe we can trigger an exception when the driver is switched to 2.x and we detect index_name, like this we can help user to edit the annotation and use copy_to ? What do you think ?

In the current solution we silently ignore something that should not work. But to have a working situation we should have ... distinct annotations for 1.x and 2.x ... so hard to say:

• Solution 1: Use the same concept than in the ContentRepositoryAdapter (Driver Pattern)
• Solution 2: This current solution, silently ignore ... but it smell bad to me

[dfeyer]

Silently ignoring should breaking existing project, basically if two fields use the same value for index_name, both field value are merged in a single elasticsearch field or if index_name is different from the model property name, this feature rename the field in elastic.

So if we ignore this field (and the value does not match the field name), the field will be empty ... so the index is broken.

[kdambekalns]

For the ES v5 adjustments I decided to transparently map some things that have been changed compared to v2. Maybe in this case we could do the same, and for 2.x automatically transform index_name to copy_to, while logging a warning about it?

[kdambekalns]

Ah, but then again… I really like the driver pattern approach!

[bweinzierl]

What is the status here?
I Am currently trying to update a super old Neos-Project. Besides the Neos related stuff we updated Elasticsearch from 2.x to 5.x.
There are two Problems now: Still the unwanted index_name (we hat a patch for that even back then)
Second: it is not possible to use a different type (e.g. keyword which is the replacement for not analyzed strings as i understand ist) in a multifield as it is always overwritten by the type if the parent field. So there is currently no way to use multifields at all.

[kitsunet]

AFAIK these issues have all been fixed and index_name is no longer supported, so closing.