vxquery-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eldon Carman <ecarm...@ucr.edu>
Subject Re: Issue with adding XML Node IDs
Date Sat, 06 Apr 2013 03:19:13 GMT
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

On Fri, Apr 5, 2013 at 4:23 PM, Till Westmann <till@westmann.org> 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 <ecarm002@ucr.edu> 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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message