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
#49 requires schema authors to name categories for each property in their schema. This forces schema authors to be explicit about the type of data they are recording in their application. One downside of this implementation is that it might force schema authors to include many categories to capture all possible ways users want to log data.
This opens the question about allowing users to extend schemas. They might want to 1. modify a schema in-place or 2. wrap a schema with custom categories, logic, etc.
To enable this, it would look something like:
allowing users to subscribe to existing event schema
firing a callback method that allows user to record their own schema or some other action with that event payload.
e.g. this could record from a custom schema.
schema_id="uri.to.schema"eventlog.subscribe(schema_id, callback)
defcallback(event):
# Do something with this data.
...
event.log.record(event.data)
print(event.schema_id)
# printed out: "uri.to.schema"
The text was updated successfully, but these errors were encountered:
#49 requires schema authors to name categories for each property in their schema. This forces schema authors to be explicit about the type of data they are recording in their application. One downside of this implementation is that it might force schema authors to include many categories to capture all possible ways users want to log data.
This opens the question about allowing users to extend schemas. They might want to 1. modify a schema in-place or 2. wrap a schema with custom categories, logic, etc.
To enable this, it would look something like:
The text was updated successfully, but these errors were encountered: