[YANGTOOLS-1178] Add unique indices

Blocks — Tue, 16 Jan 2024 14:48:09 +0000

As a follow-up to ~~YANGTOOLS-1177~~, integrate unique enforcement into TreeNode lifecycle as an additional index.

The problem of ~~YANGTOOLS-1177~~ solution is that it does not scale to large lists with few modifications – as there is no previous-state-index, we end up examining all children of a modified list.

In order to alleviate this, we need to keep further state in TreeNode – value vector/child node relation – and drive validation during TreeNode mutations.

In steady state (in-between mutations) there is a unique mapping between a TreeNode child and a vector of unique constraint values (i.e. an invariant):

BiMap<DataContainerNode, List<Object>> childToUnique;

for each individual 'unique' statement. Current implementation maintains this in a

HashMultimap.<UniqueValidator<?>, List<Object>>> validatorToUnique;

where a violation is triggered if a duplicate UniqueValidator/List<Object> mapping is being stored – effectively enforcing the invariant on steady state.

Current implementation is not plugged into TreeNode mutation process and therefore is O(N) where N is the number of list entries. This obviously sucks for small modifications on large lists.

The objective of this issue is to integrate UniqueValidation with TreeNode mutation process, so that unique enforcement will be O(N), but where N is the number of modified list entries.

To achieve that we need to plug into ListModificationStrategy/MapModificationStrategy and perform a guided mutation:

when we enter ListModificationStrategy.mutateChildren() we expand the BiMap to a HashMultimap<List<Object, TreeNode>>, where we track vector/child relationship
for each child, evaluate the vector mapped to that child, removing the old one and adding the new one
when we exit ListModificationStrategy.mutateChildren(), we check whether the HashMultimap is convertible into a BiMap – i.e. whether each vector has a unique child TreeNode. If it does not, we raise a violation

Note that the resulting BiMap will in reality be a BiMap for small lists – for large lists we need to decompose it to two TrieMaps, which co-evolve and maintain the mapping. This is because TrieMaps offer efficient amortized O(1) snapshot facility and partial modification.

After we exit from ListModificationStrategy with a unique index, the resulting TreeNode needs to contain these indices so that the next mutation can pick up from there and manipulate just the delta. This will probably need a forwarding TreeNode implementation to hold the one/two maps.

OpenDaylight JIRA

[YANGTOOLS-1178] Add unique indices