Solprovider Lenya Kongregate Registration for Free Flash Games and Chat with solprovider

RelationsTable

With JCR and the migration to flat storage, a new algorithm is needed to maintain the Parent-Child relationships for Resources.

The original discussion assumed that Parents would have some connection to their children, Children would have some connection to their Parents, and a Sitetree could be built by starting at the root Document Node named "index" and recursively adding each Nodes' Children. This creates several issues:
- If a Parent remembers its Children, then when a Child is removed, changes its ID, or changes Parents (moved within the Structure), the old Parent and the new Parent need to be updated. That is two extra writes and chances for errors.
- If a Child remembers its Parent, then then the Parent is removed or changes its ID, every Child must be updated. That could require many writes and chances for errors.
- Building the Sitetree from the Parent-Child relation information in the Resources does not allow for multiple Structures.

Enter two new concepts, the RelationsTable and Indexes.

Indexes handle any output with data from multiple Resources. See Indexes. Indexes depend on the RelationsTable for the hierarchies.

There is only one RelationsTable for a Publication. Each entry has 4 columns/fields: StructureName, ParentUNID, ChildUNID, and FullPath.
UPDATE 20060331: While implementing I realized Position is also required to maintain sort amongst siblings.

StructureName is used for selecting the relationships to be used. A blank StructureName specifies no Structure: the relationship only appears using Parent.getChildren() and Resource.getParents() without a StructureName. A relationship may not be added if the Child is specifying a Parent that has the Child as an ancestor for the Structure specified. A Resource is not required to specify a Parent, but a Resource without a Parent is called an Orphan, and may not appear in hierarchical Indexes.

ParentUNID and ChildUNID are the keys used to find the Resources within Content.

FullPath is the ResourceID of all ancestors and the Child Node: "/ancestorPath/parentID/childID". It is extremely useful for finding a Resource by its human-readable path. Unfortunately, if any Resource changes its ID, many Nodes in the RelationsTable would require updates. On the good side, this is an improvement from Lenya 1.2 where the DocumentIDs were unchangeable. (Assets were even more limited.) Changes to entries in the RelationsTable mark any Indexes that use the Structures changes as obsolete.

This information is used by:
Resource.getParents();
Resource.getParents(StructureName);
Resource.getChildren();
Resource.getChildren(StructureName);
Publication.getResourceByID(fullpath);
Publication.getResourceByID(fullpath, StructureName);

The last is necessary for the case where "/aaa/bbb" returns different resources for different Structures. While it violates best practice to have multiple nodes with the same ID, nothing in core should prevent that situation. getResourceByID(fullpath) is useful when the StructureName is unknown, but the results may be unpredictable if there are multiple matches.

<< ModulesIndexes >>

Contact Solprovider
Paul Ercolino