I’ve been playing with creating self-referential relationships, and it works well. Under the hood, I assume it uses a secondary table under the hood, which makes it very easy to create things like:
People
Friends People [many-to-many]
Followers People [many-to-many]
If you want to add a field to the relationship, such as a “Became Friends On” date, I’m curious if the relationship table is accessible? I’m not sure where the field would be visible–possibly as a virtual field on person.
Currently, I believe you would need to create the relationship table manually and create the rows manually. I tried this also, and it works, but the labels used in the rows are not as helpful (shows Parent or Friend, but not the person’s name).
A few notes along the way:
“Relation: Table name ‘Relation’ is invalid” – I assume it’s a db keyword or special name. It seems a bit awkward. Can table names be quoted/escaped?
Field name A is invalid – I assume it was just too short. Any reason for not allowing? I was just prototyping.
In the Data tab, how is the name/label for a row calculated? The first text field in the schema?
Mike
@mike_ekim1024 nice! Out of curiosity, did you get any helps from the docs on this or just take a crack at it yourself?
So if you were to create a self-referential relationship and then jump into the documentation explorer, you’d probably be able to find the tables - however, it would then be super difficult and unclear to create fields and manage things. Once you need to start adding that type of metadata, I’d highly recommend taking the route of building your own joins table.
Friends:
friend1: table, belongs_to user
friend2: table, belongs_to user
becameFriendsOn: DateTime
...etc
This way, you’ll be able to utilize the data builder and even relate other tables to the friend’s record (like a restaurants table for favorite restaurants).
There wasn’t much about creating self-referential tables in the docs, just that it could be done. I’m familiar with SQL, but other might have a harder time. Naming the Relation Field well sometimes takes a couple trys.
I did try out a join table, I was just pointing out that you loose the immediate value in the API Explorer. In the image below, followers and friends are using the implicit join, while relationship to/from use an explicit join table. It’s not a big thing, as when you use GraphQL you can get the data you need.
I did have a few random questions in my first post. Do you happen to know the answer to some?
fyi, I really dig the API Explorer–the code completion, the history, the documentation explorer. The only thing of course is you are viewing/mutating live data. How would one set up separate development and production databases? Simply use two workspaces?
This is what I use to connect the join table. It would be very helpful to see the SQL this generates to gauge performance. Is it using simple joins, nested queries, etc.
{
peopleList {
items {
name
relationshipTo {
items {
type
relationshipFrom {
name
}
}
}
}
}
}
Sorry for missing the original question!
Th name label is the 1st position field in the data viewer. We’re working on an update to allow for templating of the records labels. Almost like a handlebars type template.
Yes, we do a minimum field length, I’m not sure why 3 is the minimum limit! Table names are best done using snakecase or camlecase. Do you think it should be done a different way?
Being able see “John: Friend” instead of just “Friend” would be awesome when working with join tables.
Working mostly with JavaScript, camelCase feels the most natural. What other options are there?
@evgeny.semushin just shared with me that part of the GraphQL spec is two-character minimum length name! https://graphql.github.io/graphql-spec/draft/#sec-Names So that is why we do it 
Where are you suggesting “John: Friend” over “Friend”?
Also, if you run this query in the API Explorer, you’ll see that there are both displayName and name on every table. This really isn’t properly reflected right now. However, for the time being I’d encourage the use of camleCase, since all the GraphQL operations get generated accordingly. Even using snake case would look ugly (best_friendsList, best_friendCreate).
{
tablesList {
count
items {
name
displayName
}
}
}
Where are you suggesting “John: Friend” over “Friend”?
In the image in the post above, under the RELATIONSHIP TO [Parent, Friend]. Since it’s a join table, it only knows about the text field (relationship type), so that’s what you see. It would be interesting to see “John (Friend)” or something almost like how the Data Builder shows Relation Field Name.
I’m sorry, how did we get to discussion about camel case vs snake etc.?
After running that query, now I see that there are 3 name styles: User friendly displayName, the same name without spaces for name (PascalCase), and then the GraphQL camelCase name.
Ahhh that is an interesting point! Maybe it’s something good that we add once we knock out display name templates.
Lol, I thought you were asking about what naming conventions are possible when you asked:
Working mostly with JavaScript, camelCase feels the most natural. What other options are there?
