
Hi! I'm creating and testing a simple data model and I'm a bit confused about how one way relationship restrictions work with many to many relationship. I will provide an example.
I have a collection for "Users" and another collection for "Skills", every user should be able to have multiple skills. Eventually I will query users by skills but I don't want to keep track of the users in the skill collection, so I see a one way relationship.
If I make this relationship "Many to one": "members can contain one skill, skills can belong to many members" -> Then restrictions work as expected:
- Restrict: You cannot delete a skill referenced by a user, but you can delete a user that has a skill.
But if I make the relationship "Many to many" (as I want): "members can contain many skills, skills can belong to many members" -> Then restrictions work in a strange way IMHO.
- Restrict: I cannot delete users that have skills referenced but I can delete skills that are related to users.
Is this the intended behavior? I expected different behavior, more close to the "many to one" restriction, as this is a one way relation, what I expected was:
- Restrict: I shouldn't be able to delete skills that are referenced in users but I should be able to delete any user with skills without any problems.
I have IT background and I guess many to many relationships are using a hidden table to keep track of the references, and something weird must be happening with the restrictions in the pivot table.
Recommended threads
- Hola equipo de soporte,
Hola equipo de soporte, Estoy desarrollando una Function en Appwrite Cloud con Node.js 22 y el siguiente package.json: { "name": "upload-whitelist", "type"...
- Looking for Partner
I'm looking for partner for long-term collaborating. Of course, I'll pay for you. If you are interested, Please DM me.
- Issue - Migration From Cloud > Self Host...
Hi team, I’m trying to migrate a few of my Appwrite projects from the cloud to a self-hosted instance. These projects are currently in “archive mode” due to th...
