# ES for logs -- field conflict hell 🔥 **URL:** \ **Category:** Elasticsearch\ **Created:** [March 20, 2024, 8:51pm UTC](https://discuss.elastic.co/t/es-for-logs-field-conflict-hell/355849 "2024-03-20T20:51:00Z")\ **Posts on this page:** 1\ **Showing post:** 14
**Author:** ![leandrojmp](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/leandrojmp/32/107231_2.png) [@leandrojmp](https://discuss.elastic.co/u/leandrojmp)\ **Post date:** [March 25, 2024, 9:18pm UTC](https://discuss.elastic.co/t/es-for-logs-field-conflict-hell/355849/14 "2024-03-25T21:18:46Z")
> [@rsk0](#): > > I have no idea how common our scenario of logs + mixed schema + conflicts is among Elastic users, but thinking about what led us here I have to imagine there must be a sizable contingent of users in the same boat, and so Elastic must care about our use case and be interested in making it work better. It would have been good to get a sense of how much Elastic cares here, especially as internal detractors have been growing more vocal. Maybe a product manager could chime in. I would say that this kind of mapping conflict errors are pretty common, if you search on the forum you will find a lot of topics about this, but in my opinion the root cause for this is a misconception on how Elasticsearch works. Elastiscearch is not schema-less, it is schema-on-write and has some features to also have schema-on-read (like runtime fields), but having a schema (the mappings) it is a requirement. There are some ways to avoid the issues of conflicting mappings, but in the end the only solution is to fix the mappings and reduce the number of dynamic fields. This is a lot of work, but using ECS as a reference helps a lot, you can fix this on the source, like talking with the internal dev teams to adopt a common logging schema, or during ingestion, by parsing the source message and renaming the fields. --- _[View the full topic](https://discuss.elastic.co/t/es-for-logs-field-conflict-hell/355849)._