tana
  1. Bidirectional Fields

Comment #⁨7⁩

Andric Tham Andric Tham Mar 13, 2023

I posted a duplicate request before realizing this already existed. Here’s what I said:

Explain the problem as you see it

If you reference a node from within a field, that reference shows up in the “References” section of that node, not in a field within that node.

When specifying structured data (i.e. fields) on a record (i.e. a Tana node), one expects relations between two records to be handled consistently on both sides of the relationship.

In other words:
If a relation is defined as a field on a record, then the relation should show up as a field on both the incoming and outgoing side of said relation.

Instead, the current status quo uses a backlinks-style UI which is borrowed from last-generation tools like Roam, LogSeq or Obsidian which is optimized for handling relations found within unstructured text.

It feels strange that the fields and views UI are borrowed from Notion and Airtable, but bidirectional fields didn’t carry over. This mismatch of UI idioms is frustrating.

Why is this a problem for you?

This is a problem only because Notion and Airtable handles this so gracefully, and Tana does not.

Since Tana is attempting to implement a superset of Notion and Airtable’s databases, this can be classified as a feature regression of sorts, especially if a user (i.e. me) were to migrate from using one of those tools to using Tana.

Example scenario:

Let’s say I have a field inside #Task called “Projects” that is of type “Instance” referencing nodes of type #Project

Inside a #Project, I might have a field called “Tasks”, where I want to see nodes of type #Task that reference said project

This example scenario works out of the box with Notion and Airtable, and doesn’t work with Tana’s fields, which is a crying shame!

Suggest a solution

  • The easy solution: Make relationships between nodes that are defined inside a field bidirectional. This probably only makes sense for nodes that have a schema inherited from a supertag.

  • The ideal solution: A better way to define cross-schema relations, replete with the ability to visualize fields and how they relate across #Supertags, probably using some kind of boxes-and-arrows no-code UI that looks like an ER Diagram.