Impact 2024: The Industrial Data and AI Conference for and by Users | Nominate Speakers Now for a Ch...
Though if you instead query for the related type (say Role from your above types), and add a 1:1 relation back to the ‘parent’ (User in this case), you can then filter on properties of the User and Role. So the Role type and query would become type Role { ... user: User}{ listRole(filter: { and: [ { ...some filter on properties of Role }, { user: { ...some filter on properties of User } } ] }) { items { externalId roleName user { externalId } } }}
We currently don’t support filtering on properties of related nodes from a 1:many relationship. But we do support filtering on properties that are related in a 1:1 relationship.
Ok so the query endpoint is off the table here if a requirement is to get a connected structure back.Let’s try to figure out what you would require for the graphql to work. So currently with the `getById` graphql queries you can paginate through children. The problem here is that you don’t want to make multiple requests for multiple parent ids right? With the `list` queries, we don’t support pagination of children, but you can get up to 1000 children. The problem here is that 1000 is not enough right?If my above statements are true, can we talk about the use case more? Is this query for displaying data in a UI?
Our aggregate and search endpoint cannot do nested filters at this point. This is something that is on our radar though and will be fixed!
If you want the data in a connected structure, you’d have to use graphql
Absolutely you can do this. The query would look similar, but adding another key in the select statement { "with": { "0": { "limit": 50, "nodes": { "filter": { "and": [ { "matchAll": {} }, { "hasData": [ { "type": "view", "space": "someSpace", "externalId": "Well", "version": "someVersion" } ] }, { "or": [ { "equals": { "property": [ "someSpace",
“I want all the wellTests performed for Wells in region ‘West’”with graphql, you could do{ listWell(filter: { region: { eq: "West" } }) { items { wellTests { items { id passFail } } } }}is this what you’re currently trying with graphql (leading to the cursor limitation you mention)? If so that’s a bug I will look into.In terms of a workaround, the graphql layer is calling the `instances/query` endpoint, so everything possible with graphql is possible with that (and more). The body of that request would look something like this: { "with": { "0": { "limit": 50, "nodes": { "filter": { "and": [ { "matchAll": {} }, { "hasData": [ { "type": "view", "space":
The getById queries only support fetching a single item by id. Then you can paginate the children. Yes this means separate queries. Can you explain the use case though? Paginating children when multiple parents are returned gets quite confusing, and I’m not sure there’s any strong use cases beyond “give me all the data”
You can pass a limit to the nested query like this{ listMovie { items { actors(first: 1000) { items { externalId } } } }}if you want to paginate on a nested level, you need to use a `get...ById` query instead of the list query. As of now we only support pagination on the first level in list queries, and on the second level in getById queries.
Already have an account? Login
Enter your username or e-mail address. We'll send you an e-mail with instructions to reset your password.
Sorry, we're still checking this file's contents to make sure it's safe to download. Please try again in a few minutes.
Sorry, our virus scanner detected that this file isn't safe to download.