Thanks for your feedback. I found the issue in the path step. Each time a new tree is created based on the path step and the process was not considering if the previous tree had node ids. Still have an other error to track down but this issue is resolved.
I do have a question about IDs. Each node tree gets a long value for its ID. The elements in the node have a int value for their ID. How are we going to use the IDs to keep document order? Also when we create a new path step node tree, what ID should this receive? The element id is only 4 bytes while the parent node tree is 8 bytes. How do these two types of IDs work together? On Fri, Apr 5, 2013 at 4:23 PM, Till Westmann <[email protected]> wrote: > Hi, > > I'm not sure that I understand your scenario well, but I'm wondering if > you are looking at the same node tree both times? Or are you first looking > at the parent's node tree and the at the child's node tree? > It seems more likely, that the construction of the the content doesn't do > what you expect, than that the parent gets changed when extracting the > children. > > Till > > On Apr 5, 2013, at 2:01 PM, Eldon Carman <[email protected]> wrote: > > > Hi, > > > > The necessary code for adding IDs for each node tree and all the nodes in > > side the node tree has been added to my local dev copy. The issue I am > > seeing is with the header bit for node tree pointable. In the > > SAXContentHandler, the bit is set to three. Two represents the dictionary > > exists and one represents the node IDs exist. The correct actions. > > > > The issue appears when reading the node tree pointable in the child step > > function. The node tree header is no long three but two. This means that > > all references to data after the node id is now off by some offset > causing > > issue with reading data from the byte array. > > > > Any idea why this value is changing or where this could happen? > > > > Preston > >
