"Joins" - include related entity's fields in Views

Ideas & Features
1

Even one-to-one Relations/Lookups only show a link to the related entity.

It would be very useful to be able to treat the related entity’s fields as if they were “native” fields belonging to the main entity (i.e., joined).

E.g., to be able to show the related entity’s fields as columns in Table Views, or even in the main Entity View.

…especially if we can edit these related fields as if they belonged to the main entity.

2

Hi, Matt!
Maybe I didn’t get the problem - hope, you would help me here.

  1. You can use a LookUp - get the fields you’re interested in as read-only ones on any of the level, and then manipulate them using as columns/filters/anywhere

  2. If it’s more about the inheritance, you can set the same fields on all the levels and use automations to input values.

Any use case or example is would be super helpful!

1 Like
3

Yes, this is related to Inheritance-like functionality:

Example: If I have a Project Type that is related (1:1) to a SEO Info Type, my desire is for a Projects Table View that can display and edit the fields of the related SEO Info entity (if it exists).

The issues with using Lookups for this are:

  1. Each Lookup field must be manually created (cumbersome, and error-prone if field definitions change)
  2. Lookups do not allow editing the related values in the Table View
1 Like
4

Haven’t tested it yet, but maybe Automations can work?
So if you create same fields on both Entities, and they are field automatically based on each other’s values.
So the trigger will be any of the fields updating.

If I got the problem correctly, maybe this can work? How do you feel?

5

I’m not sure it’s possible to define and use rules that are mirrors of each other (i.e. “If A changes, update B” and “If B changes, update A”) since it will probably trigger loop detection. Otherwise, they would repeatedly trigger each other.

2 Likes
6

As you noted, this idea is an attempt to achieve a kind of type polymorphism – a “mixin” type. :cricket_bat_and_ball::skull_and_crossbones::horse: (beating a dead horse)

I have two motivations here:

  • make related fields transparently available in all their contexts
  • reduce the work necessary to use related fields

Manually duplicating fields into related types might work, but it is extra work, and clutters up our Types with duplicated Fields. :cry:

Ideally all our data fields are unique, existing only in a single Type, and the relationships do all the hard work to make them appear in related contexts (Types). And ideally, they could always be treated as if they were “native” fields in any context/Type where they appear.

I can dream, right?? :grin:

2 Likes
7

Definitely!
We’re dreamers too, so I’ll artefact your wonderful dreams and :crossed_fingers: some day we will see that in Fibery :slight_smile:

1 Like