58b14a83bc
Part of the fix to bug #1489618 was working only accidentally. The implicit update logic of the allocated table (and the allocatedIds dict) treated ctrl.available.sourceItems and ctrl.allocated.sourceItems as parallel arrays, while they were not parallel in fact. This change allows the sender of the CHANGED message to specify all four tables and by that spare any implicit logic of updating some of the tables. However if a table is not included in the CHANGED message it will be left unchanged. The event is also renamed according to the new meaning. The single sender of the original message from the horizon repo (ie. Launch Instance / Source) is updated. The original message type and its handler logic is removed without deprecation. That theoretically could cause problems for horizon plugins outside of the horizon repo. But I find that unlikely because if somebody had relied on that logic they would have likely discovered already that it was faulty. Change-Id: I38972558e1823f9a88702d2ebcb8de5244cfe16a Related-Change: I647b31c7a280af4e10040fb27b4436d489fd8163 Related-Bug: #1489618
14 lines
688 B
YAML
14 lines
688 B
YAML
---
|
|
other:
|
|
- |
|
|
(For Horizon plugin developers) The AVAIL_CHANGED event of transfer
|
|
table is removed. It is superseded by event TABLES_CHANGED. The
|
|
name of AVAIL_CHANGED was misleading because it implicitly and
|
|
uncontrollably updated the allocated table too. The new event allows
|
|
independent updates to all four tables. We believe it is safe to
|
|
remove AVAIL_CHANGED without deprecation because its implementation
|
|
contained a bug that must have been discovered before if anybody
|
|
had used it. Anyway possible out-of-tree plugin maintainers are
|
|
recommended to consume the new event even if your plugins relied on
|
|
the buggy behavior of AVAIL_CHANGED.
|