Open mateenkasim opened 2 months ago
One piece of context: for this use case, SpiceDB is the primary store of this data. I think in other contexts these sorts of invariants would be enforced by the API/datastore that was the primary store of the data prior to replication into SpiceDB.
Problem Statement
TLDR
I propose creating a "Set" API that receives a resource type, resource ID, and relation name as well as a subject or set of subjects, and it atomically does the following:
Abstractly, this allows for atomically setting a relationship to an exact value (or set of values) without requiring the user to read the old value, construct preconditions for avoiding race conditions, or construct explicit DELETE operations.
Description
It's established that all SpiceDB relations are essentially many-to-many relations. Consider this schema:
In this case, the many-to-many relation
enrolled
is appropriate; a class can have many enrolled students, and a student can be enrolled in many classes. Now, consider this schema:In this case, the many-to-many relation is inappropriate; a folder can have many files, but a file can have exactly one
parent
folder. If a user wantsfile.parent
to be a many-to-one relation, this must be enforced at the application level, not the DB level.Users of SpiceDB will always want to model one-to-one, many-to-one, and many-to-many relations, and I believe SpiceDB users are duplicating a lot of work to enforce these invariants at the application level. To make this easier without extending the schema, SpiceDB could expose an atomic "Set" operation that exactly defines a relation.
I consider two scenarios:
parent
folderW
ReadRelationships
to get the current subject, call itV
Precondition
that checksV
is still the current subject, call itP
V
is notnull
, create aRelationshipUpdate
to DELETE the tuple with subjectV
RelationshipUpdate
to CREATE/TOUCH the tuple with new subjectW
WriteRelationships
request usingP
and the above twoRelationshipUpdates
P
, you know someone else changed the relation concurrently. Repeat the whole process again.T
ReadRelationships
to get all current subjects, call this set of subjectsS
Precondition
that checks that all ofS
are still current subjects, call itP
S
is not empty, create aRelationshipUpdate
for eachs
$\in
$S
to DELETE the tuple with subjects
RelationshipUpdate
for eacht
$\in
$T
to CREATE/TOUCH the tuple with new subjectt
WriteRelationships
request usingP
and all the aboveRelationshipUpdates
P
, you know someone else changed the relation concurrently, potentially with another "set" operation. Repeat the whole process again.This is quite a lot of work to enforce an otherwise common DB paradigm. It would be alleviated if SpiceDB had a semantic to exactly "set" the relationship, internally handling the deletion of all previous values without requiring the user to know what those previous values were.
Solution Brainstorm
I'm not completely sure what the Set API would look like. I offer two options here, one for each scenario mentioned above.
One-to-One or Many-to-One relations, where there must be at most one (or exactly one, depends on context) subject under that relation per resource at any time
parent
folderRelationshipUpdate.Operation
:OPERATION_SET
Many-to-Many relations, which are the loose default in SpiceDB
SetRelationship
API.DeleteRelationships
API, which allows doing many deletes but can't perform Writes in the same transaction.// Clears all tuples that match the RelationshipHead // Writes new tuples using the RelationshipHead as resource/relation and the given subjects as subject message SetRelationshipRequest { RelationshipHead relationship_head = 1; repeated SubjectReference subjects = 2; }