https://www.prisma.io/ logo
Join Slack
Powered by
Quick question: recently discovered that if I crea...
# prisma-whats-new
b
Quick question: recently discovered that if I create a complex object in one mutation, say, 
user->-order->shipAddress
, all entries are created in the DB correctly except one thing: shipAddress’s ID in the order is always null. While I if create order directly with the shipAddress, e.g., 
order->shipAddress
, shipAddress’s ID is always updated correctly in the order. Is it intentionally or do I miss anything?
n
@barbatus hey, might be a bug, can you PM me the mutation?
b
ok, a bit later. I wonder though what you'd like to check there? there will just what I mentioned User with multiple dependencies inside. It's been created always correctly so far except only that IDs.
n
Having a specific mutation allows me to understand the problem better and hopefully provides me with a reproducible bug 🙂 This is very useful to investigate the problem further
b
Hey, sorry i completely forgot about it. Here is a mutation
mutation createUserAndPlaceOrder($idToken: String!, $stripeId: String!, $email: String!, $firstName: String!, $lastName: String, $phone: String!, $orders: [UserordersOrder!], $shipAddresses: [UsershipAddressesShipAddress!], $cardDetails: [UsercardDetailsCardDetail!]) {↵ createUser(authProvider: {auth0: {idToken: $idToken}}, stripeId: $stripeId, email: $email, firstName: $firstName, lastName: $lastName, phone: $phone, orders: $orders, shipAddresses: $shipAddresses, cardDetails: $cardDetails) {↵ id↵ orders(first: 1) {↵ id↵ __typename↵ }↵ __typename↵ }↵}↵
n
I'm not quite sure what exactly you mean. It looks like users are both connected to 
shipAddresses
directly, but also indirectly via 
order->shipAddress
the mutation you sent me sets the connection between 
user->shipAddresses
directly, so it shouldn't be 
null
.
However, if you create an 
user->order->shipAddress
, this does not affect 
user->shipAddresses
at all. May I ask why you have two paths between 
User
and 
ShipAddress
?
ping @barbatus
b
right, I just looked at the mutation one more time and realized that it's probably impossible to add 
shipAddress
to the user and order in one mutation
n
that's correct! But unless you have a specific reason to duplicate the connection, you really shouldn't do it anyway 🙂
is 
user->shipAddresses
semantically different to all `user->order->shipAdress`es?
b
it's not duplicated
user has 1 to many relation with the addresses and order has one specific address it's designated to
n
what's the meaning of the 1-to-many relation?
is it "all the addresses of all orders of this user"?
b
but first time when the user created the address should be added to the both tables
yes
n
Then you don't need the direct 
user->shipAddress
connection
Copy code
query {
  allShipAdresses(filter: {
    orders_some: {
      user: {
        id: "user-id"
      }
    }
  }) {
    id
  }
}
those are all ship addresses that are connected to a specific user via 
shipAddress->orders->user
b
well that's possible of course
but looks weird
i'd say the user owns addresses rather than orders
n
Then you can turn it around and remove the 
user->orders
connection, and use 
user->addresses->orders
instead
of course, you can leave it like it is as well. Then you need to manage the two paths yourself though
Which might introduce data inconsistencies (for example, an order has a ship address that is not listed in 
user->addresses
)
b
yes it's possible but hard to imagine how to introduce from the frontend side in our case. Anyways thanks for the help, i appreciate. Though tend to think continue managing these two paths, it just happens once for each user
n
ahh gotcha
then it should be pretty straight-forward indeed
either way, hope it makes sense now what happens
haha just noticed you asked like 3 weeks ago 😄
b
yeah i forgot
n
no worries! 🙂 Did you encounter any other problems or questions?
b
so far i think no more yet but I'll surely ask if encounter anything)
hey one question though got into my mind regarding the issue above. Do you think whether it'll possible some day in the future to use results from one query in another one in one requests?
n
do you have some thoughts how that could look like? This is why we came up with nested mutations, so we can extend this concept further
b
lets say something like this
mutation($email: String, $shipAddresses: [UsershipAddressesShipAddress!]) { createUser( email: $email shipAddresses: $shipAddresses ) { id shipAddresses { id } } createOrder( userId: createUser.id shipAddressId: createUser.shipAddresses[0].id ) { id } }
n
Ah gotcha. This is an interesting topic to explore, but we would need to come up with our own DSL that follows the GraphQL specification. Your query is not valid GraphQl for example.
b
yeah that's what i was thinking about - there might no any reference to anything similar in the specification
thanks!
n
likewise! pushing the boundaries is awesome 😉
2 Views
Open in Slack
PreviousNext
Powered by