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.
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.