Postmortem: Outage due to Elasticsearch’s flexibility and our carelessness

Post by vaidik » Tue, Dec 15, 2015, 12:47 PM UTC

anarazel wrote: post #18

vaidik wrote: post #17

Earlier quoted context omitted.

I might be missing something. But to my understanding I think it is correct. I didn't quite get what you exactly mean by that? Educate me please. To explain myself, I meant that tests that were succeeding previously would have failed due to this issue if we had tests written for it. Does my statement not convey this?

Original statement: > But lack of automated regression testing would have caught this issue. Your question: > To explain myself, I meant that tests that were succeeding previously would have failed due to this issue if we had tests written for it. Does my statement not convey this? No. The sentence says that the lack (i.e. not having) tests would have caught the issue. If you remove 'But lack of', the sentence makes…

Post by craigching » Tue, Dec 15, 2015, 3:09 PM UTC

vaidik wrote: post #14

shubhamjain wrote: post #10

> The values for field price in products mapping and the values for field price in promotions mapping (in the same index) will essentially be added to the same list at Lucene Segment level. And it will not fail or throw an exception. Probably a stupid question but why can't ElasticSearch translate both mappings into something like, "products_price", and "promotions_price" before adding to the 'list'?

Something I wondered too. But I think in the 2.x versions, they are already planning something around it. Honestly, I have not looked at it much yet but even creating another mapping with the same field name but different type should perhaps throw a warning or not be allowed unless overridden as they lead to things like these.

  Fields with the same name, in the same index, in different types,
  must have the same mapping

Post by vaidik » Tue, Dec 15, 2015, 4:21 PM UTC

craigching wrote: post #23

vaidik wrote: post #14

Earlier quoted context omitted.

Something I wondered too. But I think in the 2.x versions, they are already planning something around it. Honestly, I have not looked at it much yet but even creating another mapping with the same field name but different type should perhaps throw a warning or not be allowed unless overridden as they lead to things like these.

In 2.x, all fields must adhere to the same data type or you will get a failure [1]. To quote: Fields with the same name, in the same index, in different types, must have the same mapping So hopefully this isn't an issue anymore! I do strongly suggest (and we've done this from the beginning) that no one rely on elasticsearch's auto mapping and that you should explicitly map your fields. [1] -- https://www.elastic.co/g…

Post by vaidik » Tue, Dec 15, 2015, 4:47 PM UTC

notdonspaulding wrote: post #26

You've got what appears to be a vestigial comment in your article. It reads: (add more details here) But it looks like you've got plenty of details. Just thought I'd let you know ;-)

Post by gnurag » Wed, Dec 16, 2015, 4:29 PM UTC