We get the following exception when indexing our contents.

2017-11-17 13:15:50,621 [8] ERROR EPiServer.Find.Cms.ContentIndexer: MYMACHINE: An exception occurred while indexing (Content): MapperParsingException[failed to parse [_Name]]; nested: MapperParsingException[failed to parse date field [My page title], tried both date format [dateOptionalTime], and timestamp number with locale []]; nested: IllegalArgumentException[Invalid format: "My page title"]; .

I read about it and the accepted solution was Joel Abrahamsson comment:

https://world.episerver.com/forum/developer-forum/EPiServer-Search/Thread-Container/2012/8/MapperParsingException-when-indexing/#60861

You're correct, there's automatic mappings going on and this is a tricky case. Fields needs to be mapped as a type in the index so the search engine knows how to parse and index them. Creating mappings is a tedious task if done manually. Luckily elasticsearch has support for automatic mappings using templates the first time it encounters a new field. What template is used can be determined by the type of data in the field and/or naming convention.

What you have run into is a problem caused by the lack of a date format in JSON. I'm guessing that the very first document that was indexed had a PageName that only contained a date. The search engine then recognized it as a date, as a string with a date is how a date is represented in JSON, and mapped the PageName field as date. When other documents with non-date-only PageNames were indexed they failed as the search engine was expecting them to contain dates.

At this point in time this is a limitation in Find, although I definitely think it could be alleviated in the future.

So I decided to give that solution a try, so, first I removed pages which names where a date.

Then:

1. I emptied the Index and re-indexed. The same error occured when re-indexing.
2. Then I deleted the Index, created a new one and Indexed. There was no error.

It seems that the error is still there after a Clear.

So, Is there still no solution to this?

The error is only in production for now, which is unfortunate, I really don't want to delete and create a new production index.

I'm thinking that there might be a solution like this?

Client.CreateFromConfig().Conventions.ForInstancesOf().Field(x => x.Name).Modify(x => x.DeclaringType = typeof(string));

But I'm not sure that that will affect anything deep down in Elastic Search?

How do we deal with this issue?

Guess we have to assume that the customer can name the first page of pagetype as a date and we should be able to handle that correctly!

---

Starting over on a new Index:

If I add the following to our BasePageData, there is one "Name" and one "_Name" in Find:

[BackingType(typeof(PropertyString))]
public override string Name
{
get => base.Name;
set => base.Name = value;
}

Or if I add this to the find conventions:

Client.CreateFromConfig().Conventions.ForInstancesOf().Field(x => x.Name)
.Modify(property =>
{
    property.DeclaringType = typeof(string);
    property.PropertyName = "_Name";
    property.PropertyType = typeof(string);
});

Find-properties:

"Name$$string": "Page Title"

"_Name": "Page Title"

If I add the following to our BasePageData, there is two "_Name" in first level of JSON:

[BackingType(typeof(PropertyString))]
public string _Name
{
    get => Name;
    set => Name = value;
}

Find-properties:

"_Name$$string": "Page Title"

"_Name": "Page Title"

Guess that there is some magic going on, adding the _Name in the Serializer no matter how we define things in EPi!?

Then I guess there has to be investigated which _Name is used to define datatype!?

[Pasting files is not allowed][Pasting files is not allowed]