# Running an \_update\_by\_query statement dropped the field in unmatched elements?

**URL:** <https://discuss.elastic.co/t/running-an-update-by-query-statement-dropped-the-field-in-unmatched-elements/293333>\
**Category:** Elasticsearch\
**Tags:** painless\
**Created:** [January 3, 2022, 9:44am UTC](https://discuss.elastic.co/t/running-an-update-by-query-statement-dropped-the-field-in-unmatched-elements/293333 "2022-01-03T09:44:10Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![cdav](https://avatars.discourse-cdn.com/v4/letter/c/71c47a/32.png) [@cdav](https://discuss.elastic.co/u/cdav)\
**Post date:** [January 3, 2022, 9:44am UTC](https://discuss.elastic.co/t/running-an-update-by-query-statement-dropped-the-field-in-unmatched-elements/293333/1 "2022-01-03T09:44:10Z")

</div>

I've run the following query:

```auto
POST hits-*/_update_by_query
{
  "script": {
    "source": "ctx._source.type = 'se';",
    "lang": "painless"
  },
  "query": {
    "match": {
      "type": "qa"
    }
  }
}

```

Everything seemed good, but I noticed too late that every document that didn't match the query got updated to a null "type" value.

Is this a problem that can be solved with a simple operation, or is the data lost forever?

 ![Screenshot 2022-01-03 at 10.36.35 AM](https://us1.discourse-cdn.com/elastic/original/3X/e/b/eba017c013ee75e3ff72b336e6ec18e4f4729e5d.png)

Many thanks,

---

<div class="post-metadata">

**Author:** ![dadoonet](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/dadoonet/32/137187_2.png) [@dadoonet](https://discuss.elastic.co/u/dadoonet)\
**Post date:** [January 3, 2022, 10:00am UTC](https://discuss.elastic.co/t/running-an-update-by-query-statement-dropped-the-field-in-unmatched-elements/293333/2 "2022-01-03T10:00:07Z")

</div>

Welcome!

I doubt that documents have been updated with a null value when running the exact request you shared.

But to answer your question, there's no way to restore the original values unless you did a snapshot before.

---

<div class="post-metadata">

**Author:** ![cdav](https://avatars.discourse-cdn.com/v4/letter/c/71c47a/32.png) [@cdav](https://discuss.elastic.co/u/cdav)\
**Post date:** [January 3, 2022, 10:35am UTC](https://discuss.elastic.co/t/running-an-update-by-query-statement-dropped-the-field-in-unmatched-elements/293333/3 "2022-01-03T10:35:10Z")

</div>

Thank you for the welcome 🙂

I'm almost certain that this is the correct query, I know because it took an entire night to run and I saved a copy of what was on my browser before going to sleep in case it timed out.

What's making me lead towards a problem other than the query is that only ~half the documents got updated, and as far as I can tell data up to ~6 months ago had the query run on it but didn't lose any data.

I should be able to rebuild the field from a different source, but it might take close to forever.

 ![Screenshot 2022-01-03 at 11.22.19 AM](https://us1.discourse-cdn.com/elastic/original/3X/2/6/26ae19a8b42a90d4f255f82256144c6abab11177.png)

---

<div class="post-metadata">

**Author:** ![cdav](https://avatars.discourse-cdn.com/v4/letter/c/71c47a/32.png) [@cdav](https://discuss.elastic.co/u/cdav)\
**Post date:** [January 4, 2022, 9:20am UTC](https://discuss.elastic.co/t/running-an-update-by-query-statement-dropped-the-field-in-unmatched-elements/293333/5 "2022-01-04T09:20:50Z")

</div>

Ok, I believe I'm at fault here. There is no bug, just an unattentive user. The data from July onwards was corrupted because I was uploading it to elastic as such, and everything functions as intended.

---

<div class="post-metadata">

**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\
**Post date:** [February 1, 2022, 9:20am UTC](https://discuss.elastic.co/t/running-an-update-by-query-statement-dropped-the-field-in-unmatched-elements/293333/6 "2022-02-01T09:20:52Z")

</div>

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.