-
Notifications
You must be signed in to change notification settings - Fork 6
Description
We are now using a DispatchUpdate
object that only has the selector
(named as components
), dry_run
and payload
(maybe named inputs
or options
).
It might be better to send an actual Dispatch
object, in case the user needs to access more information about the particular dispatch that triggered the update.
We still need to account for potential "merges", like for now dispatches with the same type
as merged is if they were one big virtual dispatch. For example, if we are merging all dispatches with different IDs but the same type, and we have id=1 start=10:00 end=11:00
and id=2 start=11:00 end=None
, that would be merged into a dispatch with start=10:00 and end=None
).
Related to:
If we do no merging by default, then we can just return the Dispatch
object and other merge functions can have their own update types that make sense for that particular merge. For example, if we are merging by selector
as well as type
, we might not want to have the selector
in the DispatchUpdate
as it is redundant.
Originally posted by @llucax in #54 (comment)