# Updating a field in a doc with the fields been obtained from another dataset (basically joins like feature)

**URL:** <https://discuss.elastic.co/t/updating-a-field-in-a-doc-with-the-fields-been-obtained-from-another-dataset-basically-joins-like-feature/175080>\
**Category:** Elasticsearch\
**Created:** [April 3, 2019, 12:32am UTC](https://discuss.elastic.co/t/updating-a-field-in-a-doc-with-the-fields-been-obtained-from-another-dataset-basically-joins-like-feature/175080 "2019-04-03T00:32:21Z")\
**Posts on this page:** 1\
**Showing post:** 4

<div class="post-metadata">

**Author:** ![Mark\_Harwood](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/mark_harwood/32/10538_2.png) [@Mark\_Harwood](https://discuss.elastic.co/u/Mark_Harwood)\
**Post date:** [April 10, 2019, 11:00am UTC](https://discuss.elastic.co/t/updating-a-field-in-a-doc-with-the-fields-been-obtained-from-another-dataset-basically-joins-like-feature/175080/4 "2019-04-10T11:00:38Z")

</div>

Maybe you should think about maintaining an [entity-centric index](https://twitter.com/elasticmark/status/1009380268409610240) built from these events?

In your case the entity would be a "job". The example document looks like a state-change event and several of these could be summarised in a job entity. The advantage of this approach is:

1. You can reduce the cost of joining fast-changing data (multiple events can be batched into a single update to the job entity)
2. Custom attributes can be derived from multiple events e.g. "jobDuration" or "lastStatus".
3. Your update scripts can see _all_ job history and tag anomalies eg where state changes don't follow expected sequences

---

_[View the full topic](https://discuss.elastic.co/t/updating-a-field-in-a-doc-with-the-fields-been-obtained-from-another-dataset-basically-joins-like-feature/175080)._