Hi, I have a question regarding how graphcool would handle two entities such as the following:

type TwoWayLeft {
  id: ID!
  one: TwoWayRight!  // ! (required) and [] (list) thrown in for extra complication
  two: [TwoWayRight] // although even plain (modifier-free) fields would seem problematic.
}

type TwoWayRight {
  id: ID!
  three: TwoWayLeft
  four: TwoWayLeft
}

[or any number of similar problematic (from a data modeling perspective) cases]. How would graphcool know which fields on each side correspond to fields on the other side in order to setup the foreign keys/relationships in the underlying physical database schema (Postgres/SQL or NoSQL or what have you)?

@jleonard did you try to set a project up with that data model? By analysing the query we can distinguish between

one

and

two

, or between

three

and

four

@nilan which query? How do you know the correspondences between the tables for foreign key relations (which must be done from the data model only-- no queries exist or are involved at that point).

so first of all, the DB we use is AWS Aurora, which is a highly-scalable MySQL variant.

Yes, but when there are 2 or more fields between two tables, how do you know which links to which? In my example,

three

or

four

could correspond to

one

or

two

.

it's not forbidden

how would "twice for the same relation" even look in practice? can you give an example data model that would violate this rule?

I cannot give you a data model violating this rule, but I can give you a data state that violates this rule. Because this is a rule about the data state and not the data model.

ok, what state is that?

Let's say you're subscribing to products

so, on

User

I have a

[Product]

yea?

yea

so you're saying that lists with repeating items are universally forbidden?

that's what I'm saying. If you need to model this, you can use an intermediate model

ok cool. thx

may I ask why you're so interested in that question?

because i have such a model 🙂

well I tried to answer your question by saying we are treating relations as their own entity

so.. a "linking table" for all cardinalities?

now when we need to resolve a relation field, we look up this meta data and know what relation this field maps to

the choice of "relation" between one:three, one:four, two:three, two:four particularly

note the @relation(name: "Tweets")

ahh, i see. so you've extended the GQL language?

well you usually define the relations using the UI

right, but if down the road I want to take my schema to a different BaaS provider, it wouldn't work with those extensions in place

hopefully that different BaaS provider has a similar, straightforward syntax so you can write a script that migrates the IDL syntax we propose to the other option

ok, fair enough. thx for your help!

we're open to and actively pushing for a general consensus regarding the IDL syntax for matters like this

cheers!