https://www.prisma.io/ logo
Join Slack
Powered by
<@U4W0FKVL1> Team.users === [ ] is a valid entry i...
# prisma-whats-new
y
@dk0r Team.users === [] is a valid entry in the Team type
d
@yus I'm kinda new to this stuff and uncertain how your reply answers either of my questions
y
That means every Team does not require an array of users. You can add a team with an empty array of users
n
you're second statement is correct, @dk0r
d
@yus, understood that the array can be empty
Thanks @nilan what about the first statement: is it the case that every 
Team
requires an associated 
User
, but not every 
User
requires an associated 
Team
?

http://i.imgur.com/tE6uizo.png▾

n
Both directions are optional the way you sez it up
d
sez
?
set
n
yea, sorry on mobile
d
np, thanks for your reply @nilan --I'm uncertain as to why both directions are optional. That is to say, a 
Team
can optionally be related to a 
User
and a 
User
can optionally be related to a 
Team
you'll note in my screen shot that the 
User
field's team-relation is optional, but the 
Team
field's users-relation is required
n
"to - many" relational fields are always "required" in the sense that the field will never be null
if the a node is not related to any nodes via a "to-many" field, it will be []
which is not null
in GraphQL, fields that are guaranteed to be non null by the schema /type system are called required
so in that sense my previous statement is wrong
d
@nilan thanks but I'm not seeing the answer to my question from your explanation. Could you instead tell me what the impact is of having 
OPTIONAL
selected on the 
User
field's team-relation (see my screenshot)?
n
the required/optional selection there is about the team field
which is a to - one field
d
um..
n
an optional field can be null
d
are we looking @ the same screenshot?
n
a required field can't
d

http://i.imgur.com/tE6uizo.png▾

n
yep
d
Clearly the required/optional selection is on the USER field, not the Team field..
n
on the left side we see the User type
and the team field
d
Perhaps you meant to say the required/optional selection is on the team relation?
n
no
d
oh, ok. I was calling 
team Team
the relation
n
that's a relational field
d
i see you are calling it a field (aka a 
related field
)
okay, sorry
Okay, so I think my screenshot is backwards for what I want then
n
can you describe with an English sentence what you want to model?
d
I am trying to set up a relation where each Team is required to have a user but each User is not necessariyl required to have a Team
n
can a user be related to many teams in that relation? can a team be related to many users in that relation?
d
Does this model that?

http://i.imgur.com/TnTMwpL.png▾

no, a user can only be related to one particular team (assuming they are related to a team at all)
n
what about the other direction?
d
a team can be related to multiple users
n
then your previous setup was already accurate
but
you cannot express at the moment that a team must at least contain one user
a
There's actually no reason for the one side of the relationship to be required then, is there? Why is it implemented like that @nilan?
d
that's okay --a team can contain an empty list of users
n
@agartha that's why I said the previous setup was correct, there we said optional 🙂
d
@agartha I think he mentioned something earlier related to what you're asking about: https://graphcool.slack.com/archives/C0MQJ62NL/p1497134333048237?thread_ts=1497133759.022964&amp;cid=C0MQJ62NL
a
Yes, but there's no difference between null and []
d
okay, good. So then my original first statement was in fact correct? heh
@agartha oh really? I assumed null != []
I'm pretty sure there's a difference, no?
a
in theory yes, regarding relations: no
d
oh. hmm
a
It's a required field, because it requires at least an empty array []
n
I don't understand what you want to say with this
a
which is still 0 users 🙂
d
@nilan I just want to assure that I'm 'reading' the gui correctly
n
[] != null indeed
d
then what is agartha referring to?
a
That I find it really confusing
n
well I think you do 🙂 read it again and feel free to ask again
a
Let me try again: users [User!]! and users [User!] both specify a 0..n relationship, there's no way to specify a 1..n relationship, so why make the list required?
d

http://i.imgur.com/tE6uizo.png▾

Okay --regarding the following screenshot, is it correct to say that 1) a Team is required to be related to a set of users (even if that set is empty) and 2) a User is not required to be related to any particular Team
👍🏻 1
n
[User!] would be a field that either contains 0 or more elements that can never be null but must be a User OR a field that is null
it is not possible to setup a field like that at the moment
it's only possible to have [User!]!
yes that is accurate
d
Thanks @nilan --when you say 
it is not possible to setup a field like that at the moment
what do you mean by like that? ..like what?
oh wait
a
like [User!]
d
I missed [User!] versus [User!]!
a
So you end up with a required field, that is not a system field, yet you can do a create mutation without providing it...
d
hmm, I'm not certain @agartha. I think I understand @nilan's description of [User!] but idk how that differs from [User!]!
a
forget [User!], that's not possible in the console
n
I don't understand what you're saying @agartha
a
you only have [User!]!
sorry for the confusion
d
Hmm, okay. Well, I'm glad nilan confirmed I'm 'reading' the gui correctly but unfortunately I'm not settled on the subtleties of [User!]!
n
oh now I get it
a
@nilan Well, [User!]! is a required field right? Can't be null? Yet you can do a create mutation without specifying it...
n
while that's true I don't think that's relevant to the current discussion 😛
poor @dk0r must rip his hair already
a
It just confused the hell out of me seeing the first screenshot
d
nah
a
I'm sorry for side-tracking this thread
d
I'm more than willing to listen to the explanation
n
😂
d
@agartha feel free to explain it if you're bored --I'm willing to learn
if not, thats cool too --thanks for both your input
a
I'm never bored 🙂
d
heh
n
[User!]! specifies a field that contains a REQUIRED list of REQUIRED users
that's what the two ! signify
this is a guarantee that neither the list itself nor a single field can be null
a
Yes, and Graphcool has some hidden magic that makes sure, that if you don't specify an empty array in your create mutation, it creates one for you
d
yeah, as I've understood it, ! indicates a requirement. The dual !'s seems redundant
but, isn't that redundant? or no?
n
it's a useful guarantee, so you don't need to check for null in your client
d
hmm, ok
n
it's not redundant
a
That makes sense actually
Array operations work on empty arrays, but not on null values
So always having an empty array is nice for clients that expect an array
d
if the content of the array is required NOT to be null, how could the array itself be null?
n
[User!] specifies a NON REQUIRED (in other words optional) list of REQUIRED users
exactly @agartha
so while any element in the list is guaranteed to be not null, the whole list could be null from the start
d
hmm that's a bit a strange to me
a
[] is valid for [User!]!
d
if an element is non-null, there there must exist a non-null array to contain the non-null element
n
@dk0r compare that to [User]
a
[null, null] is not, because of User!
d
@agartha I agree that an empty array is not considered null
n
[null] is valid for [User] and [User]! but not the others
a

https://raw.githubusercontent.com/sogko/graphql-shorthand-notation-cheat-sheet/master/graphql-shorthand-notation-cheat-sheet.png▾

See the Type Modifiers block at the bottom of the second column
n
null is valid for [User] and [User!] but not the others
d
@agartha nice --that helps a lot for a reference. Thanks man!
a
yw
n
[] is valid for all cases
a
Yes, first ! tells you items in the list cannot be null, second ! tells you the list itself cannot be null
@nilan One last question remains though. Can you explain where the hidden magic happens for the default value?
Because if I create a field on my type with the exact same type [String!]!, the create mutation does throw an error if I don't supply it
n
hah
you have to see that we generate a GraphQL schema based on the way you setup your types, fields and relations
if you set a required field, an input field will be added to the create mutation that is required
if you add a required relational field however, the corresponding input fields will be optional
additionally, if you add a default value for a required scalar field, you don't need to specify it in the create mutation either
a
That makes sense. It would just create a lot less confusion if relation fields are defined in the schema with default value []. Then you don't need any hidden magic, and behavior is consistent.
I'll just make that a feature request 🙂
n
I dare to challenge that statement 😆 I think we need an entirely different concept for relational fields but not sure what exactly
in terms of UI that is
a
Agreed
n
that's a FR for default values for to many fields already
there's *
a
#106?
n
how could a different default value than [] look like? a list of ids?
a
well... yes, but why would you want that?
n
yes!
oh well why show a default value of you can't change it?
and I can imagine situations where you could use that
a
true
I think the abstraction layer above the actual created graphql, and the fundamental design decisions to make it 'look and feel' more like a traditional RDBMS, are causing problems in the long run
default values in graphql do not belong to types, but to queries
you don't show the queries anywhere
just the types
and then try to overlay one onto the other
I find that, being experienced with GraphQL, and not experienced with Graphcool, the only places where I stumble and fall are those places where design decisions were made to not follow GraphQL concepts.
n
what are those design decisions that don't follow GraphQL concepts
a
Well I already gave the default value example
n
yep. wondering what else there is
a
The link between types and queries. With GraphQL, those are two distinct parts
Seperately defined
Based on the needs
n
well that's true
a
It's nice to have them auto-generated, as long as you would have the option to extend, remove and change
n
the automatically generated queries avoid quite a bit of boiler plate
a
absolutely, and that's fine
unless it's all there is
n
however, the addition of custom queries will be a big win
yea I feel you there
a
then the permission system
the missing big part of graphql which are resolvers
then there's input types for mutations, so I can just pass in my JSON object, instead of having to break it up into individual mutation parameters
And one big one: the power of GraphQL is having one unified graph for all of your data sources. You have deliberately limited that to one underlying database. That, in the end, is I think a huge unexplored area for all GraphQL BaaS platforms.
Reading back on my own comments, I might just have a fundamentally different vision of what a GraphQL BaaS should be 🙂
n
Oh I don't think so 🙂 Most of what you said is already on our roadmap, so it's great to see we're aligned there. Especially your last point will be a game changer 🙂
a
Good to hear that is on the roadmap. Saves me from still having to roll my own in the end 🙂
Maybe...
👀 1
Open in Slack
PreviousNext
Powered by