Can I use a property from a higher level field as input parameter for a lower level field in a GraphQL query?
For example, a soccer club has players and seasons. In each season, a subset of the club's players play games for the club. The players of the club can have a different squad number each season.
I want to query the club's players for a season, along with their squad number for that season, and for each player I want a list of the games they have played in that season.
I can get a list of all the games (in all seasons) a player has played for the club. But I want to filter that list so only the games in the queried season are included in the list.
query {
club {
players {
fullName
}
seasons {
id <-- I want to use this value as input parameter $seasonId below
players {
edges {
squadNumber
node {
fullName
games(seasonId: $seasonId) { <-- how to use the value here?
homeTeam
awayTeam
}
}
}
}
games {
players {
edges {
goalsCount
node {
fullName
games(seasonId: $seasonId) { <-- how to use the value here?
homeTeam
awayTeam
}
}
}
}
}
}
}
}
If this is not possible, should I introduce a SeasonPlayer GraphQL type (containing the squad number of the player for a season)? Or should I use a query parameter containing the season ID?
Related
Say I want to query an object tree like this:
query UsersWithOrgs {
users {
nodes {
firstName
lastName
orgMemberships {
nodes {
joinedAt
organization {
name
foundedAt
location {
city
country
}
}
}
}
}
}
}
Now say I want to filter for only the users where the org they joinedAt <= 6 months ago, or only the users where the org they joined is in England.
query UsersWhereJoinedRecently {
users {
nodes {
firstName
lastName
orgMemberships(joinedAt: { lte: "2022/03/12" }) {
nodes {
joinedAt
organization {
name
foundedAt
location {
city
country
}
}
}
}
}
}
}
query UsersWhereOrgInEngland {
users {
nodes {
firstName
lastName
orgMemberships {
nodes {
joinedAt
organization {
name
foundedAt
location(country: "England") {
city
country
}
}
}
}
}
}
}
Is this the "GraphQL way" of defining filters on nested objects? Or should the filters be hoisted up somehow?
Based on the definitions above, I would instead expect UsersWhereJoinedRecently to return all users in the app, but orgMemberships would be filtered to only include those after the joinedAt date. Likewise, I would expect UsersWhereOrgInEngland to return all users with all their orgs, but only return the location for the org if the country is "England". That is not at all what I want, I want only the users where if that deeply nested condition is false, not to return the user. What is the appropriate way people handle this situation?
To me there are two passes in the overall query:
Joins and Wheres.
Projection.
First, we must fetch all users where the deeply nested condition is true. Then given those top-level IDs for the user, we fetch the projected schema.
So first:
// userIds =
select id from users
inner join memberships on memberships.userId = users.id
where memberships.joinedAt <= "2022/03/12"
Then:
select firstName, lastName from users where id in userIds
select joinedAt, orgId from orgMemberships where userId in userIds and joinedAt <= "2022/03/12"
... select from each of the other tables.
... then build into tree and return to client.
Same with the other query.
So because of these two seemingly completely separate phases, it makes me think that all filtering should be passed in at the top level in some fashion in GraphQL. Like:
query UsersWhereJoinedRecently {
users(membershipJoinedAt: { lte: "2022/03/12" }) {
nodes {
firstName
lastName
orgMemberships {
nodes {
joinedAt
organization {
name
foundedAt
location {
city
country
}
}
}
}
}
}
}
Is that correct, is that the recommended practice? Or what is recommended practice in these sorts of "filter by nested objects" scenarios?
I have grphql query with count for detail table.
Artist
Album
Track
Here is my query
query Artists($take: Int, $skip: Int, $orderBy: [ArtistOrderByWithRelationInput!]) {
artists(take: $take, skip: $skip, orderBy: $orderBy) {
id
name
profile_picture
_count {
albums
tracks
}
}
aggregateArtist {
_count {
id
}
}
}
What I want is I only want to get artists who has at least on song tracks. I can list the tracks count but I can't query. May I know how to query by count?
So I'm trying to learn graphql I've been playing around with the ENS subgraph on the graph
I've figured out how to do simple filtering but when I try to write more complex filters they do not compile.
I'm trying to get the top 5 transactions for the each of the top 5 domains. (e.g for each domain I want the top 5 transactions)
{
#Sample Query to get the first 5 domains (not needed for question but used to validate results)
domains(first: 5) {
id
name
labelName
labelhash
}
#attempt to filter the transfer.domain.id by TOP 5 domains.id
transfers(where: { domain { id: domains(first: 5) { id } } }) {
id
domain {
id
}
blockNumber
transactionID
}
}
EDIT I'm going to attempt to simplify my request since I'm not sure nesting queries is possible. How can I filter an inner query by Id:
transfers(where: {domain.id: "0x9c0fc2519ae862cee27778e5c34714d6c7e3ca21ad572df47ad9f6fe530909bd"}) {
id
domain {
id
}
blockNumber
transactionID
}
NOTE: Domain.Id = does not compile how would I write a filtered query like that?
However, My filter doesn't compile syntactically. How can I write a query which filters by a child property?
You can query like this
query {
getPost(id: "0x1") {
title
text
datePublished
}
}
Got this from https://dgraph.io/docs/graphql/queries/search-filtering/
I am a traditional programmer new to GraphQL and I can't seem to find documentation on what I consider the basics, aka manipulating variables. Note: I am using GraphQL with Shopify(Admin API), through an app GraphiQL, so that my effect syntax and capabilities.
Here is a piece of hypo (& broken) code where I have two iterations of the same code block
<>that tries to add two variables
<>on that sum items in a list. The specific code in this lines are guesswork..
If anyone has suggestions on sources for example code or API docs beyond GraphQL site, I have been searching and nothing I have found addresses this type of functionality.
query fiveorTenOrders($n: Int = 5,$m: list =[5,5], $boo: Boolean = true) {
FiveOrds: orders(first: $n) {
edges #include(if: $boo) {
node {
...ordrecs
}
}
}
#<<<HERE and as basic arithmetic>>>
TenOrds: orders(first: ($n+$n) {
edges #skip(if: $boo) {
node {
...ordrecs
#<<<OR HERE ...as a sum of list>>>
TenOrds: orders(first: $m:SUM {
edges #skip(if: $boo) {
node {
...ordrecs
}
}
}
}
fragment ordrecs on Order {
id
name
createdAt
shippingAddress {
id
city
provinceCode
zip
}
}
GraphQL does not currently support this sort of functionality (and may never). Variables are used as-is with no way to apply arbitrary transformations to them. In your example, you would need to sum the values yourself on the client and then inject them into the query as a separate variable.
I want to query the product using product tag, but it returned similar product tags with the given tags. I Refer some other references, it denotes the tag are tokenized field so it will return product, if any equality exists in the tags. but i want know if any possibility are there to retrieve the exact tag products
Query
query Myquery{
products(first:10, query: "tag:Switches variants.price:>=2335 variants.price:<=3000") {
edges {
node {
id
tags
variants(first:10)
{
edges
{
node
{
price
}
}
}
}
cursor
}
pageInfo {
hasNextPage
hasPreviousPage
}
}
}
Above query returns tag 'Switches' and 'Switches & Sockets' but i need tag with 'Switches' alone
You can add an exclusion but you need to know what to exclude e.g.:
{
products(first:10, query: "tag:Switches -tag:Sockets") {
edges {
node {
id
tags
variants(first:10)
{
edges
{
node
{
price
}
}
}
}
cursor
}
pageInfo {
hasNextPage
hasPreviousPage
}
}
}
You understand that tags are a string right? So if you search for the string Switches you will get back Switches, and anything else in the string. So you have the extra step of further processing your results. Split on comma into an array, and only return the products where the filter condition is equal to Switches alone.