Firebase “symlink” to another node

Question

In relation to my other question about modelling a real user-facing tree structure (Using firebase tree structure to represent a "document outline" structure directly), I was thinking of putting in place a generic approach to "symlinking", at certain nesting levels, to overcome the 32 nesting levels limitation and the need to fetch all sub-nodes at once.

Are there some "best-practices" for "symlinking" in firebase?

E.g.:

• syntax (contents, key-value structure) for a firebase node which would symbolise a link to another node
• should the symlink contain the path to the target node (absolute or relative?) or just some kind of globally unique id?
• API for a callback which would be triggered when the symlink content finishes loading asynchronously

I am envisioning a little wrapper API which would abstract the difference of whether the node is really there or is it accessed indirectly via "symlink". There could be an extra API method "now fetch me this/more" as the user wants more details on the displayed data (e.g. drilling down deeper in the tree), and it could fetch e.g. the next level of nesting (via callback), abstracting away whether the children's content was really there or just symlinked...

Does this seem like a good idea in general?

Answer 1

Perhaps you should look at how the relational world solves this problem. We can take their solutions by first transforming the tree nodes to documents. This means for a tree

root 0
|-- top child I
+-- top child II
    |-- second-level child 1
    |   +-- third-level child a
    |-- second-level child 2

you will have a document for each of the six tree nodes. Then have additional data in the documents describing the tree structure.

I have been inspired by this SO answer which outlines three approaches with pros and cons. Let me show here how these approaches apply for a document-oriented database.

Approach with parent id

Add a field parentId which contains the document id or some other unique value of the parent node.

pros and cons:
+ easy to understand, cheap insert, cheap subtree move
- difficult to retrieve subtree

Modified Preorder Tree Traversal

Add two fields left and right to contain the indexes of the traversal. First start with the root node and assign 1 to left, then descend to top child I and assign 2 to left. If there are no more children, assign the next integer to right. Then go up one level and assign the next integer to right.

For more details, please see this old but still excellent guide: Modified Preorder Tree Traversal on Sitepoint.

pros and cons:
+ cheap retrieve of subtree, ordering of children guaranteed
- difficult to understand, expensive insert (repeat tree traversal)

Save the Path in the Node

Use some unique value (like the document id) and create a path of these unique values starting with root and descending down to the node. For example the path for the second level child 2 might be "0/II/2". Or create an array ['0', 'II', '2'].

pros and cons:
+ cheap retrieve of subtree, cheap insert
- expensive subtree move