Hi, > the change log is calculated from the resulting states
That's anyway a bad idea. It's complex, doesn't work correctly for move and reorder operations, and is inefficient. It's a lot simpler and more efficient to build the change log based on the JCR operations. And it will ensure the result is correct. I wouldn't worry about "optimizing" the change log. If the user added a node and then removed the very same node within the same change log, then it's his own problem if it's slightly slower. Optimizing for user errors makes absolutely no sense. Regards, Thomas On 5/22/12 12:00 AM, "Michael Dürig" <mdue...@apache.org> wrote: > >Hi, > >During my work on OAK-102 and OAK-106 I was eventually convinced by >Jukka to switch from using a change log to accumulate transient changes >to an approach where the change log is calculated from the resulting >states instead. Now this seems to bite already. Witing large child node >lists seems to be trouble some wrt. performance: since the comparison >needs to iterate over ever more child nodes, writing child nodes does >not scale in constant time any more but rather in time linear to the >total number of child nodes. That is, adding the n-th node takes approx. >n times as long than adding the first node did. > >Michael
