Projector implementation #585
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Power-cycled to rerun CI with fixes in master related to docs. |
|
One random failure. Merging! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Implementation of projector that can be called with a BlueskyRun, reading a projection as specified in bluesky/event-model#179
This is the result of lots of discussion with @ronpandolfi and @tacaswell.
The result is an xarray.Dataset. Single value fields (like those that might appear in the start doc) would be projected into the Dataset's attrs field. Multi-value event stream fields appear in the Dataset with the projection's key and a Datarray value.
The projection can also support calculable fields. The projection type "calculation" can specify a callable that can be invoked by the projector to populate a Datarray into the return Dataset.
There was also a suggestion for a static type in projections where a value was pulled directly out of the projection. I'm open to this, but left it out for now. I think a lot of thought needs to go into what types of values are supported.
I had originally defined a class structure for projectors, but was convinced that since I wasn't storing state, that a function was good enough.