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
We propose that the we add to the query request schema a timestamp field so that consumers of UBI data can know when the query was made. This timestamp field would mirror the existing timestamp field defined in the event schema:
We actually have in the OpenSearch UBI plugin that we track queries by a Unix Epoch field, so we capture the specific date time. But that is a different format than what we use for events. We also support a "date" but not a "datetime", so this needs fixing in the UBI plugin for OpenSearch anyway.
What problems are you trying to solve?
Consistency in the UBI specification and the UBI plugin, and moving to using ISO 8601 formatted time stamps everywhere to simplify down stream users of UBI data.
Yes, if you used Chorus for OpenSearch edition, then you would need to update. In the future this might cause a major version bump in the spec, but today, I think it's niche enough we use it as a chance to bump the minor version.
What is the user experience going to be?
Simpler consumption of the data.
Are there breaking changes to the User Experience?
Yes, if you used epoch formatted dates you need to switch to ISO 8601 format.
Why should it be built? Any reason not to?
Definitly let's change now before UBI becomes even more widespread ;-)/
What will it take to execute?
Update UBI Spec
Update UBI for OpenSearch Plugin schema defintion
Update Chorus for OPenSearch to change format of dates being sent.
Documentation and samples updates.
Any remaining open questions?
No.
The text was updated successfully, but these errors were encountered:
There is already a timestamp field in the queries mapping. What we can do is if the user provides a timestamp in the search request, the UBI plugin can use it instead of now.
This is a revamped version, where we take out the required nature, and articulate two use cases for why you might want to provide the timestamp instead of letting the UBI plugin for the search engine do it.
What/Why
What are you proposing?
We propose that the we add to the query request schema a
timestamp
field so that consumers of UBI data can know when the query was made. Thistimestamp
field would mirror the existingtimestamp
field defined in the event schema:https://o19s.github.io/ubi/docs/html/1.1.0/event.schema.html#timestamp
What users have asked for this feature?
We actually have in the OpenSearch UBI plugin that we track queries by a Unix Epoch field, so we capture the specific date time. But that is a different format than what we use for events. We also support a "date" but not a "datetime", so this needs fixing in the UBI plugin for OpenSearch anyway.
What problems are you trying to solve?
Consistency in the UBI specification and the UBI plugin, and moving to using ISO 8601 formatted time stamps everywhere to simplify down stream users of UBI data.
This bug was discovered by @alexeyrodriguez during his work to simulate UBI formatted data. Thanks @alexeyrodriguez!
Are there any breaking changes to the Spec
Yes, if you used Chorus for OpenSearch edition, then you would need to update. In the future this might cause a major version bump in the spec, but today, I think it's niche enough we use it as a chance to bump the minor version.
What is the user experience going to be?
Simpler consumption of the data.
Are there breaking changes to the User Experience?
Yes, if you used epoch formatted dates you need to switch to ISO 8601 format.
Why should it be built? Any reason not to?
Definitly let's change now before UBI becomes even more widespread ;-)/
What will it take to execute?
Any remaining open questions?
No.
The text was updated successfully, but these errors were encountered: