How does the mapping functionality perform joins under hood ?

​@Anita Hæhre ​@Mithila Jayalath  is that the right place to share this post ? 

​@Alex If this question need to be visible only to TotalEnergies and Cognite, this is the correct place. If not the product user community is the correct place.

​@Mithila Jayalath how can I move that ?

​@Oussama ALLALI I can move it for you. Just to confirm, you want to move this post to the product user community ?

​@Mithila Jayalath yes please !

This won’t perform any joins. This just means you’ll populate both the Well and Casing containers for the same node. What you want is a direct relation pointing from Casing to Well i.e.

```
type Casing {
  name: String
  well: Well
```

then when you query for nested properties like `Casing.well.name` the query executor will perform a join using the identifier defined in the direct relation property (which essentially acts as a foreign key here).

​Hi ​@erlend.vollset 

Thanks for your response.

What I'm trying to achieve is to display some well information directly in the tabular view of the casing object, without creating an explicit link between Casing and Well.

I’m not sure I fully understand the part about populating both the Well and Casing containers for the same node — could you clarify what that means in practice? Are you referring to a situation where the same node instance contains attributes from both types?

My goal is really to avoid duplicating well information across objects like Casing, and instead make it available through the view logic — for example, having a view of Casing that shows name, diameter, and also the well_name, even if well_name is not stored in the container itself.

Is there a way to achieve this kind of virtual enrichment in the view without relying on a direct relation?

I’m not sure I fully understand the part about populating both the Well and Casing containers for the same node — could you clarify what that means in practice? Are you referring to a situation where the same node instance contains attributes from both types?

Yes, exactly. With that approach you’d need to duplicate the Well name on each Casing node, which would be very cumbersome to maintain.

What’s the reason you want to avoid using direct relations? That is in fact _the_ way to achieve this kind of enrichment, you won’t be duplicating any data, just referencing the Well nodes from the Casing nodes. When performing queries you can then pull in any additional related data.

​@erlend.vollset in fact, our users use cdf tabular view. They want to see these informations without run any queries.

Which part of the UI is the “cdf tabular view”? I think this should then be filed as a feature request in the tabular view - i.e. to be able to denormalize certain properties on types through direct relation properties. ​@Mithila Jayalath, can you follow that up?