We lack robust support for processes with more than one port to the same store.
The multi-update workaround introduced in #28 allows ports that point to multiple leaf stores to share leaf stores. In this case, updates to the shared leaf stores are aggregated into lists and applied sequentially.
Unfortunately, this workaround is very fragile. Here is an non-exhaustive list of scenarios that break this solution:
The process defines an initial_state method that provides initial values for the overlapping ports (patched in #205)
The overlapping stores contain values of type dict
The topology for one or more of the the overlapping ports is a dict instead of a tuple (e.g. port: {'_path': ('bulk',)})
One or more of the overlapping ports points directly to a single leaf store instead of multiple
One potential solution is to generate individual updates for each port and apply them in sequence.
We lack robust support for processes with more than one port to the same store.
The multi-update workaround introduced in #28 allows ports that point to multiple leaf stores to share leaf stores. In this case, updates to the shared leaf stores are aggregated into lists and applied sequentially.
Unfortunately, this workaround is very fragile. Here is an non-exhaustive list of scenarios that break this solution:
initial_statemethod that provides initial values for the overlapping ports (patched in #205)dictdictinstead of atuple(e.g.port: {'_path': ('bulk',)})One potential solution is to generate individual updates for each port and apply them in sequence.