=== Text from other discussion The hierarchical index must exist, but does not need to be reflected in the data structure. We have discussed moving to a flat structure for Document storage. In relational databases, even the hierarchical index would be stored in a flat structure: UNID - ParentKey DocumentUNID - ParentDocumentUNID getParent(UNID) getAllChildren(ParentUNID)
An alternative would allow a document to have several parents: Key - ParentKey - IsPrimary DocumentUNID - ParentDocumentUNID - True|False getPrimaryParent(UNID) getAllParents(UNID) getAllChildren(UNID) getAllPrimaryChildren(UNID) JCR allows more options for the structure, but we still have to decide if we want the ability for a document to have several parents. This functionality may be useful in rare cases. Is it worth the additional complexity to make Lenya useful for those cases? It would be much more difficult to add it later than to integrate it during the migration to JCR. === End original text This assumes Lenya uses a flat structure for document storage: UNID (Unique Identifer) = one Document. Document contains ParentUNID. There would be an index to represent the hierarchical structure (similar to sitetree.xml) /foo /foo/aaa /foo/bbb Each references the document in the flat structure using its UNID. This proposal is for Documents to have additional Parents: Document - ParentUNID - OtherParentUNIDs Then we can have multiple indexes for creating the menus. One would be the standard OneParentPerChild index. Another would show the AllParents. Example: Document "aaa" has ParentUNID for "foo". It also lists "other1" and "other2" as alternate parents. "other1" is a top-level document, and "other2" is under top-level document "parent2". The standard one-parent index looks like: /foo /foo/aaa /other1 /parent2 /parent2/other2 The multiple-parent index would look like: /foo /foo/aaa /other1 /other1/aaa /parent2 /parent2/other2 /parent2/other2/aaa This allows a document to appear at several places in the hierarchy. In the other discussion about Lenya's structure, I wrote that: getUNID(url) getPrimaryURL(unid) would be easy, but: getAllURLs(unid) could be difficult, but this function could return the URLs for the document for each of its parents. If we want to allow multiple parents, this functionality should be designed into the core as early as possible. Adding it later could require rewriting many basic functions. Specifically it means the addition of a Document property to store the multiple parents, and support for multiple indexes. A related idea is to allow "softlink" documents, where a document exists, but just points to another document. It allows similar functionality, but requires more work from the editors. It also requires more work for getAllURLs(), since a document does not know all the paths for reaching it. "Multiple parents" and "Softlink documents" are not mutually exclusive; adding both increases flexibility. solprovider --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
