https://www.prisma.io/ logo
Join Slack
Powered by
Def get used to using the sandbox to query and mut...
# prisma-whats-new
d
Def get used to using the sandbox to query and mutate as soon as possible
d
@doug_w Thanks, Dough
I think I've identified three graphcool types for my app: Users, Events and Teams
The app is for sports club management, so users will have roles of Player, Parent, Coach and Admin
One of the things I'm confused about atm is..
A player can only belong to one team in a particular season, and so I believe theres a one-to-one relation b/w players and teams
But what happens if I want to store a history of teams that a player has played on?
d
I think you will need to break your model into CurrentTeam and PastTeams
d
Do I just make a new 
teamHistory
attribute on a 
User
or do I change the relation ship type to many-to-many?
d
Don’t be afraid to make new schemas to make sense of you data. graph.cool is so fast you can have so many
User has team and pastTeams
It’s ok to have extra stuff because you only make queries for the exact data you are looking for
d
okay --so then I'll keep the one-to-one relationship between User and Team
d
yeah I would just clarify the data point is CurrentTeam
d
And how would you implement previousTeams?
d
It’s not quite one to one because a team has many users. One to many
d
oh, I see.
d
Just create previous teams as a property of user and set it to a relationship of team
d
So don't categorize a relationship based on the direction you are traversing the relationship in
d
no not neccessarily
user has a team, team has many users. One to many no matter how you look at it
d
understood --so then basically, currentTeam will be a one-to-many, and previousTeam will be many-to-many?
d
Exactly
d
I have a follow up on that 🙂
From my reading, I've understood that you generally make relations (edges) between nodes (tables)
d
and as I stated earlier just create the relathionship and figure out how to make a mutation in the playground. You will learn real fast if it won’t work out - and it’s super easy to re implement!
Yup that’s correct
d
However, what you are suggesting is to make relations (edges) between props that belong inside of a Node (table)
d
The data node is the only way to make the relationship
d
Okay, so let me see here..
In this example, there is a User type/node and a Team type/node, agreed?
First off, I don't think there's much diff between a type and a node. The only diff between type and node seems to depend on whether or not a relation (edge) exists
d
yeah agreed
d
for example, a type is just a type. But a type with relations (edges) to other types, turns those types into nodes
is that ^ your understanding?
d
hmm I think everything is a node wether it has a relation or not
d
okay, so then I'll treat types and nodes as synonymous then?
d
I think so but I guess I am not 100% on that
d
An instantiation of a type is called a node. The collection of all nodes is what you would refer to as "your data". The term node refers to a node inside your data graph.
Okay, so moving on to my question then
d
ok yeah that looks good then
d
I currently have three nodes: 
User
, 
Team
and 
Event
d
yup
d
And we can create different types of relations between these nodes
d
yup
d
However, in this example, the 
User
node can have props like 
currentTeam
and 
previousTeam
.
And what you are suggesting is to create a one-to-many relation from the 
currentTeam
prop to the 
Team
node, is that correct?
d
correct
d
I want to be clear on this because for some reason, I have the idea that relations (edges) can only be created between nodes
d
Well you are using the term 
prop
which is actually a node
d
Okay --if that's the case then you are implying that we can have nested 
Nodes
, correct?
d
In graph databases everything is simply a node
d
Node
User{ 
Node
name: string, 
Node
currentTeam: relation-to-Team-Node }
oh, ok.
well good --I'm going to try implementing this then
Thanks for the clarifications
Open in Slack
PreviousNext
Powered by