https://www.prisma.io/ logo
Join Slack
Powered by
I need a solution to define rules where the data i...
# prisma-whats-new
k
I need a solution to define rules where the data is not repeated as in the following photo. ref:https://www.awesomescreenshot.com/image/2862343/c4e0b16262dfceec97b619a8db4d39ff
n
we'll release a proposal for multi-field unique constraints & more soon 😉 stay tuned!
👍 1
e
Or you could just make a relation from photo to user, and call it photolikes. Then you can just query for the count of users that have liked a photo
Depending on how you need to access the data, this might save a good bit of process
k
Hello @eruby, I do not know if it works well since I need an accountant (of how many likes that user gave and how many likes have a photo besides) for both entities: user and photo, what do you think?
e
I mean if you don't have any real purpose of tracking user likes beyond a count, you can create a number that you increment on the user object every time you have a like. Since multi-field uniqueness is not currently supported, and without knowing the timeline for it you may need to pursue another option
You know your data model best, so its a matter of what makes the most since given your unique situation
n
you can also easily adjist the_query_ to return the right count, no matter how many times a user liked a photo
Copy code
query {
  _allUsersMeta(filter: {
    likedPhotos_some: {
      id: "my-photo-id"
    }
  }) {
    count
  }
}
💯 1
e
I redact my soution. This is a better approach. You will be better off modifying the query later on, rather than having an unneeded tracker if you plan to switch over time (less migration in the long run).
k
Thanks, I'll try.
It does not work well because every time I go to write new data I would have to send all the ids of the user's photos plus the new like and nose would be very secure that way.
I was trying
e
You should be able to just filter on query, then your structure of data remains the same
Basically, you don't care about duplicate likes because you know that the query for like count will ignore a duplication
The only downside, is that you leave open the opportunity to bloat your record count via duplicates.
Like the system would know, but the front end would not show it because your query would filter usercount by users who have liked a particular photo.
If you want to actually prevent a duplicate record from being made, that gets a bit hairy
k
I was referring to the moment of adding new likes to this user, in the query if everything is perfect.
You can graph the solution of two entities (user, photo) + tastes, please
e
tastes?
k
with favorites i meant
e
so likes?
k
yes
I would like to see if the state understood well what I mean by the idea
e
One sec. I'll make a dummy graphcool and share the voyager snap
k
👍 Thank you
2 Views
Open in Slack
PreviousNext
Powered by