[YANGTOOLS-921] Design insert/move operations on top of ordered (leaf-)lists Created: 02/Dec/18 Updated: 19/Sep/23 |
|
| Status: | Confirmed |
| Project: | yangtools |
| Component/s: | data-impl |
| Affects Version/s: | None |
| Fix Version/s: | 14.0.0 |
| Type: | New Feature | Priority: | Medium |
| Reporter: | Robert Varga | Assignee: | Unassigned |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||
| Epic Link: | MD-SAL patch | ||||||||||||
| Description |
|
In order to implement MDSAL-246 we need a way how to express insert/move operations within ordered lists. This should be a two-step process, with this issue dealing with the frontend operations and internal representation, i.e. how does the user express the operations and how they are tracked and applied within InMemoryDataTree. The results of these operations can result in straight overwrites being reported by the DataTreeCandidate and improving the situation there should be a separate effort. |
| Comments |
| Comment by Robert Varga [ 03/Dec/18 ] |
|
This requires two things:
As for naming, it would seem the correct term would be 'KeyValueList', as the we really care about iteration order and need insert (of which append/prepend are special cases) and a move operation. Two instances are only equal if the order of key/value pairs matches. Aside from these, we do want to provide Map operations, but need to define how a replace operation behaves with respect to iteration order (is it replace or remove-and-append?) As for MapAdaptor: ImmutableMap conforms to the contract with efficient move (but not insert) if we break into package-private constructor. Even if we do not do that, we need to provide at least a singleton specialization and quite possibly 'small' and 'large' implementations, to mimic what we do with HashMap vs. TrieMap. |