[YANGTOOLS-938] InMemoryDataStore delete/write cycle produces unexpected result Created: 28/Jan/19 Updated: 30/Jan/19 Resolved: 30/Jan/19 |
|
| Status: | Resolved |
| Project: | yangtools |
| Component/s: | None |
| Affects Version/s: | 2.0.16, 2.1.8 |
| Fix Version/s: | 3.0.0, 2.0.17, 2.1.9 |
| Type: | Bug | Priority: | High |
| Reporter: | Robert Varga | Assignee: | Robert Varga |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Description |
|
Given the model: container foo {
leaf bar {
type string;
}
}
performing the following operations: tx.delete(foo); tx.write(foo/bar, value); will not result in the leaf being present. This seems to be operation merging bug coming from automatic container lifecycle: previously this stacking would not have been allowed, as the parent does not exist. With automatic lifecycle, though, the container is transiently created and therefore this stacking is completely valid – performing these operations in two separate transactions produces a result where bar is present. |
| Comments |
| Comment by Robert Varga [ 28/Jan/19 ] |
|
The problem is that the DELETE operation does not consider children at all, as when it is sealed, deleted nodes are not supposed to have any children. A trivial approach would be to turn all deletes into empty writes, but that ends up performing unnecessary operations (and changes behavior asserted by a unit test) Rather than that, delete operations should be expanded into empty writes only when they have a child operation introduced. This also allows us to reject writes into deleted presence containers earlier. |