Allow schemas to be extended
- Dominant language
- Python
- Stars
- 51
- Forks
- 19
- PR merge metrics
- No merged PRs in 30d
Description
#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.
```python
schema_id = "uri.to.schema"
eventlog.subscribe(schema_id, callback)
def callback(event):
# Do something with this data.
...
event.log.record(event.data)
print(event.schema_id)
# printed out: "uri.to.schema"
```
Contributor guide
No contributing guide indexed for this repository
Research direction
Start with issue #49 to understand the required schema categories, then inspect the existing event-logging and schema APIs in the repository. Use the Python example in this issue to clarify the desired subscription and callback behavior; done should include a decided, documented way to extend or wrap an existing schema.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- observability-sre
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100