yeah that makes sense, just needed a rubber duck, thanks!

https://buf.build/authzed/api/docs/main/authzed.api.v1#ExpandPermissionTree the expaned api lets you walk from objects -> subjects, which would let you find all of the users associated with a team (assuming you had a permission that aggregated them)

I've concluded in our case it makes sense to make sure everyone is a

member

. So you shouldn't be only

account_manager

, but rather both member and AM. That way we can look at only member, and also give the possibility of associating a person with a team/org unit without associating them with a role. Though I'm still uncertain if that makes sense, or if we should rather just have the distinct roles and let

member

be a permission that combines all

yeah in the former you're going to have to write two relationships to add them to a role

if you use the

member

as a permission you can do something like this:

definition business_unit {
  relation direct_member: user
  relation account_manager: user
  relation sales_director: user

  permission member = direct_member + account_manager + sales_director

@User @User is there a way to query e.g for all

account_manager

across all `business_unit`s? So effectively the same as

for unit in units:
  unit->account_manager

or similar

Still trying to understand the ReadRelationship API

yeah you can do that with readrelationships, but only for direct relations

Quick, kind of dumb question -- if I do a bulk create relationship using the API and there's a duplicate relationship in the set I'm trying to create, do all the relationships get rolled back or only the duplicate one? I have a suspicion it's the former but I wanted to double check

@User yep. Its all done in a transaction and rolled back

you can also use preconditions to check things yourself as well

you can also use TOUCH instead of CREATE if you don't want that error to be raised

Is there any chance there's a TOUCH-like function in the JDK? Or does the bulk create in the JDK always throw that error?

The Java library does support TOUCH via the RelationshipBuilder -- the same place you'd specify CREATE as the operation:

java
RelationshipUpdate.newBuilder().setOperation(RelationshipUpdate.Operation.OPERATION_TOUCH).setRelationship(...)

Amazing, thanks so much!!

Does anyone know how to model relationships on documents with states? Say a document can be in these states

ACQUIRED

,

VALIDATED

and

PROCESSED

Some users can only read documents with ACQUIRED state while others can see documents with

VALIDATED

state. Is this something that is a common case? Thanks

not as common, but doable

you can create a relation for each state to place users into, and a means of linking to that relation when the document's state changes

so as an example

one option: write the user to each associated relation, and then write a relation linking the

viewer_state

to the associated relation in the same document, based on its state:

definition user {}

definition document {
  relation acquired_viewer: user
  relation validated_viewer: user
  relation processed_viewer: user

  relation viewer_state: document#acquired_viewer | document#validated_viewer | document#processed_viewer
 
  permission view = viewer_state
}

another option would be to have a distinct

documentstate

definition:

definition user {}

definition documentstate {
  relation viewer: user
  permission view = viewer
}

definition document {
  relation state: documentstate
  permission view = state->view
}

in this design, you have three resources for each document, representing the three states, with associated users. When you want to change the state of the document, you simply change the relationship between a

document

and its

state

, and it gets the associated users that can view in that state

this latter example has a nice property that you can add additional states down the road, or have a document in multiple states at once (if you like)

and you don't need to define a

{statename}_viewer

for each state

https://play.authzed.com/s/EtIhCYeNoCMP/schema is an example of the second

Many thanks! the second one looks simpler 🙂 this is great.

[Disclaimer: I have no benchmarks nor specific metrics to aim for, just a lot of battle scars fixing N+1 bugs] Is there a way to batch CheckPermission requests to minimize the number of hoops between my server and SpiceDB and SpiceDB and its store? Being able to CheckPermissions on multiple objects for a single subject would also help.

hi @User, currently the recommended practice is to execute the checks in parallel, which should scale better than a batch process. gRPC uses http/2 to allow multiple different streams over a single connection

SpiceDB will also automatically cache subproblems and attempt to reuse them in a consistent manner whenever possible

Sorry, probably shouldn't have used a loaded word like "batched". I meant being able check for several permissions in SpiceDB as part of one roundtrip, have it call its store only once (ideally, or the least amount of times possible), and get everything back as one response. As an analogy, if I have to get 5 items from a database I can call

SELECT * FROM item WHERE id = ?

5 times, or I can call

SELECT * FROM item where id IN (?, ?, ?, ?, ?)

and get a response with far less network overhead. Ideally, I'd like to do the equivalent to the latter with SpiceDB. If firing 5 goroutines and calling it a day is the best it can do, that's something I can deal with for now, but if I can avoid it that'd be sweet.

well, traditionally the reason you do an

IN

is because you want to ensure a single connection is used, and the data is loaded efficiently. With SpiceDB, on the other hand, making the calls in a goroutine will be close to ideal because (a) you're making them via gRPC, which will multiplex the calls across a single http/2 connection (b) SpiceDB is designed to process those requests in parallel and (c) the caching and single dispatch systems should reuse as many of the subproblem results as is reasonably possible