Filter by multiple variables in graphQL

Sorry, I cannot find anything on the correct syntax for this.
My query with one exposed variable works fine:

> query {
>   interviews (where: {
>          identifyingData: {
>        some : {
>          entity : { variable: {eq: "visit2"}}
>          answerCode : { eq: 1}
>        }
>      }
>   })
>   {
>     nodes {
>       key
>     }
>   }
> }

but how can I add another variable to the filter?
Adding another entity line gives an error:

> There can be only one input field named "entity".

Thanks in advance for any help,

Klaus

Greetings Klaus,

I believe in your case you could user and/or operators on the same level as identifyingData. Lemme try to show you on this example:

In this case the query will be:

query interviews {
  interviews (
    workspace: "primary"
		where: {
			identifyingData: {
				some: {
					entity: {
						variable: {
							eq: "stringVar"
						}
					}
					value: {
						startsWith: "Klaus Example One"
					}
				}
			}
			and: {
				identifyingData: {
					some: {
						entity: {
							variable: {
								eq: "intVar"
							}
						}
						valueLong: {
							eq: 220
						}
					}
				}				
			}
		}
  ) {
    filteredCount
    nodes {
      key
    }
  }
}

Result:

{
	"data": {
		"interviews": {
			"filteredCount": 1,
			"nodes": [
				{
					"key": "07-72-72-24"
				}
			]
		}
	}
}

Have a good day.

Thank you, this lets me add a second condition, which is good!
However, I have 5 exposed variables I want to use for filtering, something like:
expvar1 == 1
expvar2 != 1
. . .
expvar5 > 0

I cannot include another “and:” because it is a field.
identifyingData is a “ListFilterInputTypeOfIdentifyEntityValueFilterInput”, therefore apparently indicating it can take a list of items. I am not able to enter a list of anything, however.

Got your point. In this case I would suggest next:

query interviews {
  interviews (
    workspace: "primary"
		where: {
			and: [
				{
					identifyingData: {
						some: {
							entity: {
								variable: {
									eq: "stringVar"
								}
							},
							value: {
								startsWith: "Klaus Example One"
							}
						}
					}
				},
				{
					identifyingData: {
						some: {
							entity: {
								variable: {
									eq: "intVar"
								}
							},
							valueLong: {
								gt: 201
							}
						}
					}
				}
			]
		}
  ) {
    filteredCount
    nodes {
      key
    }
  }
}
1 Like

Perfect!

and: [ x, y, z]

does it. I would never have thought of square brackets.

Thanks a lot,
Klaus

I know I always say this but let me share my opinion again - @klaus would it not be ‘better’ to use language-specific client library, so that (once implemented in it) users don’t need to think of the manually forming graphql queries? what language do you use? if python, I have this already implemented in ssaw package. If R - perhaps it would be better to coordinate with @michael_wild and @arthurshaw2002 and contribute to the same repo/package so that three of you and then all other R users benefit?

The power of graphql’s expressive syntax allows to specify complex queries but comes with a cost of being ‘not too intuitive’, writing boilerplate code once and mapping these apis to the native client implementation is the way to go in my opinion.

Zurab, I agree with your approach. I am using R for my applications accessing the SuSo APIs. So the functionality I need is not currently available.
As to your suggestion to contribute to a common R API implementation initiative, I would certainly contribute if such an initiative is created.
I also agree with you about the power of the graphQL queries already available in SuSo. The more I learn about their structure and syntax, the better I will be able to contribute to a future R API initiative.

I myself am not an R user so cannot comment on the ‘quality’ or coverage of functionality by either of these two packages, but both @arthurshaw2002 's GitHub - arthur-shaw/susoapi: R interface for Survey Solutions' APIs and @michael_wild 's GitHub - michael-cw/SurveySolutionsAPI: Different R functions to access the Survey Solutions RESTful API packages seem to attract user’s attention and comments. Ideally (again, my personal opinion) would be great if those two would join as well, but you can take a look at see if any of those fulfills your needs and expectations and whether you would consider adding your contribution there instead of needing to maintain your own set of commands…