Greetings and happy Friday!
# spicedbb
bouffs_80692_96856
04/05/2024, 5:14 PMGreetings and happy Friday!
I'm a new user of SpiceDB and have a few use-case and schema related questions. (I'll create a thread and add the questions under it).
The schema to reference is available here:
https://play.authzed.com/s/ixr3F_HfIoNG/schema
bouffs_80692_96856
04/05/2024, 5:14 PM1. Our use case a requires bi-directional relationship between objects.
We achieved this by specifying both sides of the relationship.
Is there a nicer way of acheiving this? Could we have leveraged other capabilities in the schema language?
(In the sample schema: see how 'device' and 'ticket' have references to each other)
bouffs_80692_96856
04/05/2024, 5:14 PM2. Via the gRPC client, we issue a LookupResourcesRequest
We encounter the following error if we request listing resources where there is a cycle in the schema:
io.grpc.StatusRuntimeException: RESOURCE_EXHAUSTED: the request has exceeded the allowable maximum depth of 50: this usually indicates a recursive or too deep data dependency. See: https://spicedb.dev/d/debug-max-depth
(Note the URL in the error does not work).
Is this a bug or limitation? What can we do to acheive our use case?
(In the example schema: we wish to obtain a list of tickets a user has read permissions)
bouffs_80692_96856
04/05/2024, 5:15 PM3. Is there a means of modelling a temporary relationship?
(In the example schema: a user (tech) should get temporary access to a site, while working on the ticket - but not after it is resolved)
j
Joey
04/05/2024, 5:46 PM@Sam ^ can you look into the broken URL?
Joey
04/05/2024, 5:47 PM3. If they have access for a reasonable amount of time, we’d recommend just deleting the relationship when the access should be complete
Joey
04/05/2024, 5:47 PMOtherwise you can use caveats
s
Sam
04/05/2024, 6:22 PMYup I’ll fix it
m
mrvnknns_39360
04/06/2024, 5:08 AMIIRC there's no way to traverse the graph backwards, so you'll have to specify the relationship in both directions. The downside of this is obviously that it doubles the number of relations, but it should be fine if you actually use them.
I think this will also solve the circular dependency issue. Instead of directly referencing ticket and device as you're currently doing with
Copy code
relation ticket: ticket Copy code
relation device_ticket:ticket Copy code
relation ticket_device:device