You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, behind the covers, the OS UBI plugin tracks when you make a query request all the document id's that have been matched for the query that will be sent to the user. We store this like:
This is from the OpenSearch ubi_queries index!
However, when we wrote the pure JavaScript client, ubi.js, we did not implement that because those two fields are not in the query.request.schema.json. Indeed, it tracks slightly different:
Also from OpenSearch ubi_queries index.
So, one more wrinkle. Our mappings and demo dashboards all use "query_response_hit_ids" instead of "query_response_object_ids", as it's highlighting these are hits from the query. To get things aligned, we are going to use that terminology everywhere.
This would an optional property....
The text was updated successfully, but these errors were encountered:
Currently, behind the covers, the OS UBI plugin tracks when you make a query request all the document id's that have been matched for the query that will be sent to the user. We store this like:
This is from the OpenSearch
ubi_queries
index!However, when we wrote the pure JavaScript client,
ubi.js
, we did not implement that because those two fields are not in thequery.request.schema.json
. Indeed, it tracks slightly different:Also from OpenSearch
ubi_queries
index.So, one more wrinkle. Our mappings and demo dashboards all use "query_response_hit_ids" instead of "query_response_object_ids", as it's highlighting these are hits from the query. To get things aligned, we are going to use that terminology everywhere.
This would an optional property....
The text was updated successfully, but these errors were encountered: