Naming reverse related fields

[Aichnerc]

Summary

I have a table customers that contains two foreign keys (coach, partner), which reference its own table. Using GraphQL, I aim to design a query that would allow me to retrieve customers along with their associated coach and partner, both of which are also customers. However, the current GraphQL schema only provides a single customers field on customersEdge, which does not differentiate between coach and partner.

query getCustomers {
  customersCollection {
    edges {
      node {
        id
        name
        coach { <-- Should resolve the related customer
          name
        }
        partner { <-- Should resolve the related customer
          name
        }
      }
    }
  }
}

Instead, my query looks like this, combining both foreign keys under a single customers field without a clear way to distinguish between the two roles:

query getCustomers {
  customersCollection {
    edges {
      node {
        id
        name
        customers { <-- Resolves me just one foreign key. No way for me to seperate between coaches and partners.
          name
        }
      }
    }
  }
}

Is there a method or workaround to achieve the desired query structure?

Rationale

Creating distinct fields for coach and partner within the customers query is essential for clarity and to accurately represent the relationships within our data model. This would allow consumers of the GraphQL API to specifically request the data they need and understand the relationships between different customers.

Design

I do not have any known solutions.

Alternatives

• Use a Custom Resolver: Not sure on how to to that though.
• Database Views: Create database views that pre-join the necessary data. Increases complexity for one-to-many relationsships. Not suitable.
• Supabase Functions: Not sure this is performant, nor the right approach.

Unresolved Questions

• Schema Generation: How can auto-generated GraphQL schemas be adjusted to accurately represent these kinds of relationships?
• Best Practices: Are there established best practices or patterns within the Supabase community for handling similar scenarios?

[olirice]

dupe of #345

the explanation of how to resolve is here: #345 (comment)

Previously we decided that the current behavior is expected but this has come up enough times we might need to revisit.

Do you have any suggestions for what behavior you'd find more intuitive?

[olirice]

for example we could do

customers and customers2 to make both accessible and nudge people to manually rename one or both of the constraints with a comment directive

a challenge there would be that if the foreign key under customers gets changed, customers2 would get renamed to customers which could be confusing

[Aichnerc]

Thanks for the quick response!

I'm inclined towards the first option of making every relationship accessible and encouraging users to rename them. Is it feasible to display the actual column name in this process?

Additionally, I've scoured the documentation, searched online, reached out to the Supabase community, and even consulted GPT, but unfortunately, I couldn't find any information on this topic.

[olirice]

The solution is in docs here https://supabase.github.io/pg_graphql/configuration/#relationships-field but you're right that we should explicitly call out this issue as something it can address if we don't resolve it with the customers, customers2 solution in the next release