Hi all - I've got a 1:many question. Trying to do ...
# prisma-whats-new
k
Hi all - I've got a 1:many question. Trying to do a basic blog, and I've got a Post type, which can have many Tags. I want to facilitate creating new tags on the fly. When I create a new Post, I'm able to pass in an array of
tagsIds
(for existing tags) + an array of new Tags objects, and all is well. But, it seems like when I go to update an existing post, this behavior doesn't work - the new tags overwrite whatever I'm sending as far as existing tags. Anyone else encountered this scenario and have a suggested way to handle it?
w
@kgoggin If you try to add tags by updating a post, it will overwrite existing tags
instead, you want to create relations directly, if you already have the tags
look for the set* mutations in your playground. You can use those to create a relation between two existing entities
k
@wallslide yeah, I saw in the docs about modifying an edge. Just seems a shame to have to fire of a mutation per new Tag that way, whereas when I'm creating a new post I can do everything in one shot
w
In your case, it would be
addTo*
if there is a many sided relation
are tags shared among many Posts? Are you sure its not a many to many relation?
k
yeah, you're right, it's many:many
w
In that case you could create a third Model whose nodes store the relationship between Posts and Tags
k
Hmmm. that's an interesting idea
so one node in that model would represent the connection between a post and a tag?
w
After thinking about it, it doesn't seem to be relevant to your use case. Your problem is that people might add a bunch of Tags to a Post, and you don't want to fire a mutation per new Tag added to the Post right?
Since there's no concat or addToSet functionality, probably the best thing you can do is either update how you were doing it, but add all the previous tags' ids to the list of new ids as well, so that you don't lose any tags when you overwrite a Post's list of tags
or as an alternative, you can have multiple mutation calls in a single graphql call. They will execute sequentially though.
k
yeah, i don't even think that'd work because I have no idea how many mutations I'd actually need. I can't think of another way to handle it besides multiple mutations as separate calls.
seems like it has to be: 1. determine if any of the added tags are new tags 2. Create each new tag as a separate mutation, and save off the ids as they come back 3. Finally do my "update" mutation with the list of the existing tags + new tag ids
the part that bugs me is that I don't have to go through all this on the create mutation - that one handles the existence of existing tags + new tags side by side with no trouble. i'm kind of wondering if it's a bug or something
w
why not just combine both the new and old tags together, and overwrite the post's existing tag ids with the new combined set of ids?