https://www.prisma.io/ logo
Join Slack
Powered by
So, in that ^ gist, what is it that makes Subscrib...
# prisma-whats-new
d
So, in that ^ gist, what is it that makes Subscriber => Subscription a 
one-to-many
relation?
✅ 1
👍 1
a
@dk0r The fact that it's an Array?
Subscription has Array brackets around it, making it 'many'.
d
Yeah but this happens in the first snippet as well, which is a many-to-many
a
You asked for the difference between 1-1 and 1-n...
The difference between 1-n and n-n can only be seen by looking at both sides of the relation
If both are an Array, it's n-n, if one is an Array, it's 1-n, if neither is an Array, it's 1-1.
d
Hmm. In the 2nd snippet, both are Arrays and the site refers to this relation as a 
one-to-many
a
No, in your second snippet (the gist), the Subscriber in Subscription is NOT an Array...
d
ohh geez
a
subscriptions: [Subscription] subscriber: Subscriber
See?
d
yeah, I see it now
..my bad --thanks man!
👍🏻 1
a
No worries...
🙏 1
And remember, if you use a meta-type like described in the link, a n-n relationship is modelled as two 1-n relationships to the meta-type
d
@agartha I'm a bit new to databases --I've understood what you've said to mean that a n-n relation is really just two separate relations (1-n and n-1) but I'm uncertain what the implication of that info is..
a
With Graphcool, you can model a n-n relationship directly, without needing a meta type like in the link. Both sides of the relationship will be an Array.

https://upload.wikimedia.org/wikipedia/commons/thumb/c/c4/CPT-Databases-ManytoMany.svg/460px-CPT-Databases-ManytoMany.svg.png▾

This same relationship, in tradition SQL type databases that don't store arrays in a single field, n-n relationships are generally modelled using a cross-reference table

https://upload.wikimedia.org/wikipedia/commons/0/02/Databases-ManyToManyWJunction.jpg▾

You can also use a cross-reference table (Graphcool calls them meta-types), if you need to store additional information on a relation.
That last part is described in the first link you posted
Just select new relationship - many to many in the console if you don't need the meta-type.
d
I was trying to write my schema by hand for now
a
In that case, both ends are an array
d
Okay, well both ends being arrays is what was shown in the first snippet as such:
Copy code
type Subscriber {
  id: ID
  name: String!
  topics: [Topic] @relation(name: "FollowedTopics")
}

type Topic {
  id: ID
  title: String!
  followers: [Subscriber] @relation(name: "FollowedTopics")
}
But that ^ is different from a cross-reference table which Graphcool calls 
meta-types
?
a
Yes, simple as that
It allows you to query followers directly on Topic
d
understood. I was a bit confused about what the cross-reference table (
meta-type
) was but it seems that I've yet to come across 
meta-types
yet
Thanks again for the explanation
a
like the example in the link, if you want to know subscribedAt, you have no place to store that in a direct many-to-many relationship.
d
Oh, no.
a
That's where the meta-type would come in.
d
In the 2nd snippet they are using meta-types
ok, ty.
👍🏻 1
n
But that ^ is different from a cross-reference table which Graphcool calls 
meta-types
?
Maybe you have a better terminology, @dk0r? It's just the first name that came to my mind when writing that tutorial
a
https://en.wikipedia.org/wiki/Many-to-many_(data_model) uses standard terminology of an association table or cross-reference table. The latter is the most used term I guess...
n
Interesting, I'll think about that. The thing is that a type in GraphQL is not a table. It's similar, though
a
To bridge the gap between people used to traditional SQL databases it might help
n
That's a good point indeed
Thanks for the valuable discussion guys ❤️
👍🏻 1
a
By the way, the term 'relationship' you use is also related to traditional SQL
MongoDb for example uses the term 'association' in their documentation
n
Well, sure. But this is also a general concept you find in life 😛
a
True, although many-to-many and 1-to-many relationships are less common 😄
n
haha I'll give you that
a
And it would be, let's say, peculiar if you need a database to keep track of them 😄
d
@nilan i don't have any terminology improvements for that article. But as a database noob, I failed to understand the difference between direct relations and metatypes from the articles explanation --it took agartha's explanation to make me see it
also, the 
Structuring your Data Schema
section (linked below) is very poor imo: https://www.graph.cool/docs/tutorials/thinking-in-terms-of-graphs-ahsoow1ool/#structuring-your-data
At the bottom of the section, this graphic has no explanation https://images.graph.cool/ciwkuhq2s0dbf0131rcb3isiq/cj2qpljco002d0153zjhzqjxj/2051x10000
I guess the graphic is just trying to convey that 
Portraits
are not directly linked to 
Customers
except through 
Orders
. The explanation and graphic are poor imo
n
Thanks for your feedback 🙂 this article has been written over half a year ago and should probably be revisited completely. Can you help me out with some of the questions/concepts your interested to understand? This helps me improving the current article or coming up with a new one 🙂
d
The concepts the article addresses are fine imo. I think that overall, it does succeed at addressing an intro to types, nodes and relations/edges. The problem I personally had with the article was the wording of the 
Structuring your Data Schema
section linked below: https://www.graph.cool/docs/tutorials/thinking-in-terms-of-graphs-ahsoow1ool/#structuring-your-data-schema
..Especially in the 
Relations
subsection
The explanations in the 
Relations
subsection (linked below) are poorly/confusingly written imo and there is no explanation given for the customer-order-portrait graphic that is provided: https://www.graph.cool/docs/tutorials/thinking-in-terms-of-graphs-ahsoow1ool/#relations
n
absolutely, I created a ticket here: https://github.com/graphcool/content/issues/157 thanks so much for your feedback 🙏
do you think it would help to add a schema file of the schema discussed in the article and add a chapter solely about that?
d
I personally did not expect to see a schema in this article since it is titled 
Thinking in Terms of Graphs
. However.. that's not a bad idea at all --I'll add that suggestion to my comment on the issue page
a
These guys have a cool explanation series on graph modelling, maybe it provides some inspiration https://neo4j.com/blog/data-modeling-basics/
d
Thanks @agartha --funny, I was thinking about bothering you specifically for some learning resources
👍🏻 1
@agartha in the article you linked above, they 
enrich
the whiteboard model as shown below. What are these 
enrichments
(e.g. Database:Asset, App:Assett, VM:Assett, etc..) in graphcool terminology?

https://s3.amazonaws.com/dev.assets.neo4j.com/wp-content/uploads/graph-databases-for-beginners-data-modeling-basics.jpg▾

Are 
enrichments
considered graphcool 
types
? If so, why are there two entries in a 
enrichment
(aka 
type
)? For example, 
Database:Asset
has two entries (Database and Asset)
a
Asset is the Interface
Yes, enriching is defining Types and Interfaces, along with named relationships
d
@agartha thanks. Reading through link below to determine diff between Types and Interaces --link isn't very clear for me: https://www.graph.cool/docs/faq/graphql-sdl-schema-definition-language-kr84dktnp0/
a
Interface description in your first link is correct, though it lacks any added value to the understanding of why they exist, and the benefit they give on queries
d
Thanks, your link was a lot more helpful --If I've understood correctly, it looks like interface/type is the equivalent of class/object in object oriented programming
i.e. inheritance
a
No, it's the equivalent of Interface -> Class in OOP
Object would be the record in the table
d
Hm, okay. Is a record just a specific element in a table? Also, what's diff between object vs record?
a
Object is just the row in the table
d
Thanks again --stumbling on a lot of vocabulary here 😕 If record == table-row, then what are a table-column and a specific element in a table referred to as?
a
table-column = field
d
Any name for a specific element? i.e. what would you call the piece of data located at [3,2] (record=3, field=2)
a
Object field
As opposed to Type field
I guess
d
So then, the following: [row,column] = element
a
Actually, Graphcool calls records 'nodes'
d
corresponds to: [record, field] = object field
ahh
so [node, field] = object field
Thanks again, aga
a
well, if they're called nodes, that would make it a node field i guess...
😜 1
SQL: Table, column, record GraphQL: Type, field, node
🙏 1
d
@agartha If you get time, I'd love to have someone experienced walk me through my first schema creation to provide guidance and pitfall avoidance. Let me know if you're interested --I'd be willing to pay for your time
a
Not sure how the guys at Graphcool would feel about that, as they also offer consultancy. And I'm not affiliated to them. @nilan?
n
I was thinking about hosting a webinar that deals about data modelling and schema capabilities and all this terminology before. We don't do consultancy, but I really enjoy talking to people in webinars 😉

https://www.youtube.com/watch?v=O8vwXEbnbFk&list=PLn2e1F9Rfr6lIFF39awTAO7mrzpZabFcj▾

I don't have any hard feelings whatsoever though if you feel like helping out, @agartha 😄 I think it's a great idea to share experience
Also feel free to post for consultant help in the forums, @dk0r: https://www.graph.cool/forum/c/matchmaking
a
Great, if Graphcool is not doing consultancy services, I'm available @dk0r 🙂
👍 1
d
Okay, great. I'm studying the videos nilan posted will definitely take you up on the offer, aga. Are you available during the weekends (Sat/Sun)?
a
I usually am..., just send me a PM when you're getting there
👍 1
2 Views
Open in Slack
PreviousNext
Powered by