Trees are a layer of logic responsible for indexing trees into associative structures.

The tree system is designed to be flexible enough to be used on any associative structure. The Tree link type allows you to create your own index tree. One such tree creates an index space isolated from other trees. With TreeIncludeNode, TreeIncludeDown or TreeIncludeFromCurrentTo and TreeIncludeUp or TreeIncludeToCurrentFrom and TreeIncludeIn TreeIncludeOut TreeIncludeFromCurrent TreeIncludeToCurrent TreeIncludeCurrentFrom TreeIncludeCurrentTo link types you can define an index space for a set of link types in specified directions.

⭐ One link can be in multiple trees at once.

⭐ One tree can go through many links of many types at once in different directions.

🚫 Transactions that cause recursion in indexed data are aborted. There is currently no support for recursions in trees. We are working on it.

Now, (at the time of version 0.1.0-alpha.0) this is a separate table mp with indexes. Marks are automatically created and removed based on changes in links table. This is done by a special trigger in the ‣ repository.

Thanks to it, you can get tree-like data without traverse, multiple joins or recursive loops, or answer questions about the inclusion of one link in another faster.

For easy understanding trees available as tree in graphql schema.

Let's prepare the types for a reproducible example.

<aside> ‼️ Attention! IDs may not match, as they are taken from different examples. Be careful with mutations.

</aside>

• Insert type A

• Insert type B=A|=>A (insert type B where “from” link type could be only A, and “to” link type could be only A)

• Insert type C=A|=>A

• insert tree by types A and B, but not by C

• insert links instances of types A , B and C types, recreating scheme represented above

Example traverse by structure without using trees

<aside> ❕ For queries, it is desirable to create indexing trees in advance. Traverse/joins/recursive queries are not recommended as they are not performance efficient.

</aside>

• _or hierarchical version (cost=427.69..427.70)
• _or all by type without semantic (cost=10.07..10.08)

Create Tree for A and B but not C

mutation {
  insert_links(objects: {
    type_id: 36, # Tree
    out: { data: [
      {
        type_id: 37, # TreeIncludeDown
        to_id: 330, # B type
      },
      {
        type_id: 39, # TreeIncludeNode
        to_id: 328 # A type
      },
    ] },
  }) {
    returning { id }
  }
}

{
  "data": {
    "insert_links": {
      "returning": [
        {
          "id": 353
        }
      ]
    }
  }
}

Relations down and up

<aside> ❕ Here are examples of the most efficient ways that we recommend using for working with tree data.

</aside>

• down GraphQL field (cost=32.06..32.07)
• up GraphQL field (cost=32.06..32.07)
• _by_item and path_item_id (cost=21.14..21.15)

<aside> ❕ More about our multiparental multidirectional associative Materialized Path algorithm:

• article Links materialized paths
• GitHub repository ‣

</aside>