Frontend engineer here, slowly improving at using Elasticsearch.
Does anyone have any advice on how to best work with document _ids, specifically with regards to sending them to the front end after a _search or _get along with the _source data?
The application I've inherited has had various approaches applied; stored copies of the _id as _source.id, mixing in _id as part of the returned results, etc, etc.
Note that we have our own Express back end which calls Elasticsearch, then sends flattened results to the front end like so:
{ id: hit._id, ...hit._source }
Are there any best practices, specifically with regards to a fairly general CRUD app?
Clearly we need the _id in order to make updates, and we would like to find a balance between sending back clean data we can pass around the app, and not writing code which would make a more experienced Elastic practitioner wince.
It is clearly not as straightforward as it would have been with SQL.
this will return four value. for that job#. which is also my _id
Then I created dictionary record like this
mylist = [{"_index": "your_index", "_id": "4139835950", "_op_type": "update", "_source": {"my_new_field": "9.98654"}}]
and created list of such entry. once list is 5000 count I used bulk helper to write back to index
I'm good with the search and update APIs, the thrust of my question was really how folks structure the data returned from an Elastic _search or _get to be consumed by the front end application.
Do they:
1 ) Pass back the whole hit and reference _id and _src separately in the frontend code, i.e. model._id and model._source.name:
I'm talking about the data passed from Elastic to the front end application (perhaps in a _search reequest) not the data passed to Elastic via an _update request. I shall update the post to disambiguate.
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant
logo are trademarks of the
Apache Software Foundation
in the United States and/or other countries.