Actually, absolutely all items in a tree that is in a collection share a unique
CollectionTreeInfo instance, so that the TreeId, position, etc, exist only once
physically. JSON items point to it (as before), and node items have their XML
tree point to it.
JSON items only have a non-NULL pointer to CollectionTreeInfo if they are in a
collection. The CollectionTreeInfo instance is created upon an
attachToCollection call and delete upon detachFromCollection.
XML nodes also have a pointer if they are not in a collection, because the tree
ID (among others) is also needed at some places (like structural URIs) even if
they are not in a collection. In such a case, i.e., the XML tree is not in a
collection, the XML tree needs to instantiate its own CollectionTreeInfo (with
a NULL collection pointer). It will be deleted upon insertion in a collection
and replaced with the collection-tree-wide instance. It will be recreated upon
quitting the collection.
Finally, note that the root of an XML tree (mostly used for garbage collection
if I am correct) might be different from the overall root of the tree in the
collection (which might be a JSON item). An XML tree can "become" in a
collection either directly (through attachToCollection), in which case these
roots are the same, or indirectly (through setCollectionTreeInfo) if it was
inserted in a JSON item that is in a collection.
I hope this helps. Does it make sense?
Your team Zorba Coders is subscribed to branch lp:zorba.
Mailing list: https://launchpad.net/~zorba-coders
Post to : email@example.com
Unsubscribe : https://launchpad.net/~zorba-coders
More help : https://help.launchpad.net/ListHelp