Contexts
By default, all logs within a project are stored in the default context (represented by the empty string ""
).
When no context is specified in the interface or the table, then the default context is used. However, you can group your logs into non-overlapping contexts, which can then be displayed in separate tables.
Context Handling
You can use with unify.Context("..."):
to create a context, and all logging inside this block will adopt this context.
IMG
These can also be arbitrarily nested, where each context string is joined via /
to define the full context path.
IMG
By default, unify.Context("...")
also changes the behaviour of get_logs
, returning only the logs relevant within the context.
This behaviour can be change by setting unify.Context("...", mode="read")
which will only set the context for log getting,
and unify.Context("...", mode="write")
which will only set the context for log setting.
This makes it easy to quickly get/set different logs for different purposes throughout your codebase, without needing to manage contexts via local variables.
Shared Logs
Logs can be added to as many contexts as you’d like, without duplication.
If any logs are then updated inplace, they will be reflected in all contexts.
GIF
Note that in this case, Results
and Failed
are disconnected, and both sets of logs cannot be viewed in a single table.
To organize data in a single table, you can use column contexts, more on those soon!