Implements a mechanism to lock/unlock the SortedListProvider and bags-list iter.
WIP and currently implementing Option 1.
Goals:
Add a new method to trait SortedListProvider to allow locking and unlocking the ordering of the list's elements.
Implement a mechanism to lock and unlock the ordering of the list iterator returned by SortedListProvider::iter() implementation of the bags-list.
When the lock is set, allow all the bags list mutations that do not change the order of the iterator.
Option 1.
Return err List::ReorderingNotAllowed whenever a bags-list extrinsic or SortedListProvider method is called that may affect the iterator ordering while the lock is set, ie:
SortedListProvider::on_insert (inserting ID in the list will change the iter)
SortedListProvider::on_update (updating an ID score may cause a rebag)
SortedListProvider::on_remove (removing an ID in the list will change the iter)
BagsList::call::rebag
BagsList::call::put_in_front_of
BagsList::call::put_in_front_of_other
Even tough this approach is simple to implement and can be implemented all at the bags-list level, it may be too strict as some of the sorted list provider method calls may not affect the iter ordering or their implementation could be refactored to apply score mutations without changing the iter ordering e.g. on_update scores without rebag, on_remove do not remove the node from the list, etc.
Option 2.
Same as option 1, but refactor the sorted list provider implementation to ensure that all list mutations happen but ensure the list ordering does not change if the lock is set.
Implements a mechanism to lock/unlock the
SortedListProvider
and bags-list iter.WIP and currently implementing Option 1.
Goals:
trait SortedListProvider
to allow locking and unlocking the ordering of the list's elements.SortedListProvider::iter()
implementation of the bags-list.Option 1.
Return err
List::ReorderingNotAllowed
whenever a bags-list extrinsic orSortedListProvider
method is called that may affect the iterator ordering while the lock is set, ie:SortedListProvider::on_insert
(inserting ID in the list will change the iter)SortedListProvider::on_update
(updating an ID score may cause a rebag)SortedListProvider::on_remove
(removing an ID in the list will change the iter)BagsList::call::rebag
BagsList::call::put_in_front_of
BagsList::call::put_in_front_of_other
Even tough this approach is simple to implement and can be implemented all at the bags-list level, it may be too strict as some of the sorted list provider method calls may not affect the iter ordering or their implementation could be refactored to apply score mutations without changing the iter ordering e.g.
on_update
scores without rebag,on_remove
do not remove the node from the list, etc.Option 2.
Same as option 1, but refactor the sorted list provider implementation to ensure that all list mutations happen but ensure the list ordering does not change if the lock is set.