Skip to main content

Hello Team,

I have a modeling question.

We want to add some well information to all object types in our knowledge graph. At the same time, we don't want to create a link from the objects to the well.

So, to avoid data duplication and updating these pieces of information, I thought about using the mapping functionality.

For example, I have a casing object with two attributes: name and diameter. And I added a name_well attribute using the mapping functionality, which, as I understand, under the hood, performs a join.

type Well {
name: String
}

type Casing {
name: String
name_well: String @mapping(container: "Well", property: "name")
diameter: Float32
}

Well transformation:


select
wh.IDWELL as externalId,
wh.WELLNAME as name
from
well-data as wh

Casing transformation

select
cas.IDCASING AS externalId,
cas.NAME AS name,
cas.DIAMETER as diameter,
wh.WELLNAME as name_well
from
casing-data as cas
join well-data as wh on cas.IDWELL == cas.IDWELL

What I don’t understand is how exactly this join is performed under the 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?


@erlend.vollset this UI 

 


@erlend.vollset  so in CDF, is the mapping functionality only meant to create a view from attributes within the same container or from containers that belong to the same node ?  

Can it not be used to encapsulate a join between adjacent nodes (i.e., across containers connected by an implicit or logical relationship)?


@erlend.vollset  so in CDF, is the mapping functionality only meant to create a view from attributes within the same container or from containers that belong to the same node ?  

Containers populated on the same node.


Can it not be used to encapsulate a join between adjacent nodes (i.e., across containers connected by an implicit or logical relationship)?

No, this is not what views do.


Reply