Hi Roland
> the problem is, that when calling the methods of the
> CachingHierarchyManager the nodes i ask for will be cached in the
> idCache in a wrong state (i. e.: before actually reordering the elements).
> so if i want f.ex. delete the node b after reordering, the node will
> be looked up in the idCache. in the cache the index of node b is still 2
> (actually it should be 3) and so the wrong node will be deleted!
I'm not too familiar with the HierarchyManager and the PathMap
constructs, but I assume that the problem might be related to
orderBefore only modifying the state of the parent node. It could be
that the cache entries for the affected child nodes are not updated.
The effect of reordering nodes should immediately be reflected in the
CachingHierarchyManager and there are also unit tests verifying this.
Can you provide us a simple, isolated test program that exhibits this
erroneous behaviour?
Kind regards
Dominique
