Skip to main content

Hi everyone,

While querying the CogniteAsset view, I encountered an error when including the activities field in the selection. The API returns the following message:

 

"Cannot traverse lists of direct relations inwards."

 

Upon investigating, I noticed that the activities field in the CogniteAsset view is defined as a @reverseDirectRelation:

 

activities: sCogniteActivity] @reverseDirectRelation(throughProperty: "assets")
 

In turn, the assets field in the CogniteActivity view is defined as a list of direct relations:

assets: tCogniteAsset] @directRelation

This makes sense as the root cause, since reverse traversal over a list of direct relations is not allowed, which explains the error.

Given that this field leads to an invalid query pattern and always results in an error, should the activities field be removed from the CogniteAsset view to avoid confusion and runtime errors?

 

Here’s a minimal query that reproduces the issue:

query MyQuery {
  listCogniteAsset {
    items {
      aliases
      activities {
        items {
          externalId
        }
      }
    }
  }
}
 

Thanks!

​@Uzair Wali will you be able to help out here?

Hi ​@Lucas Rosa Alves 

Thanks for the good write up. 

And yes, we are in agreement here - the GrahpQL schema should not offer queries that lead to errors. This has been discussed and identified as an improvement we want to make. We will duly note your comment on this one. 

 

Regards

 

Arild Eide

Hi ​@Lucas Rosa Alves, thanks for highlighting the concern.

The reverse direct connection definitions on the view help us understand the context of a 'reverse lookup’ relationship, whether a singular or a multiple Direct Relation on the other end. Looking up a singular reverse relation is relatively cheaper (Postgres), hence why we have support for it in our GraphQL query interface. In case of a list of Direct Relations as a reverse relation, the queries can be exponentially more expensive, and hence we currently do not support resolving them in GraphQL interface today, however we do want client's to be able to use the definition of the relationship to be able to do their own, more efficient 'search’ queries client side, so those properties will continue to exist on the View definition.

Until we support list of DR in reverse in some manner for GraphQL, I do agree that those properties should perhaps not be exposed in GraphQL interface at least. I will raise the ticket for this and update this post accordingly.

​@Uzair Wali  - Thanks for the response and for raising the ticket.

Just to confirm my understanding of your point:

however we do want client's to be able to use the definition of the relationship to be able to do their own, more efficient 'search’ queries client side, so those properties will continue to exist on the View definition.

If I want to query on the client side, the reversed DR should not be necessary in the view definition since it can't be used to navigate through the graph during the query execution, even using the DMS API. So, the "join" between the two entities should be done in memory.

Please let me know if I misunderstood anything.

Reply


Terms & ConditionsCookie Settings