https://authzed.com logo
Join Discord
Powered by
quick question: when using a lock relation (as in ...
# spicedb
a
quick question: when using a lock relation (as in the zanzibar lock tuple / preconditions), is there a meaningful difference between using a simple monotonically increasing version resource ID for the lock (e.g. lock:1, lock:2, etc) vs using something like a uuid (e.g. lock:${uuid}, lock:${new uuid})? In the former (1, 2, etc.), locks would be "shared" among resources, so if I looked up resources that had a "lock" relation to "lock:1" I might get a large response. This in and of itself isn't very significant to me, but I'm wondering if that's indicative of some larger possible inefficiency or scaling problem. In other words, would it be at all beneficial to have distinct lock resources to "spread out" the graph so to speak, or does it not really matter?
Or perhaps it's beneficial to have viewer distinct lock resources...?
j
what are you intending to use the lock relationship for?
a
Same as this prior context: https://discord.com/channels/844600078504951838/844600078948630559/1070100910715437076 – basically we need to limit the number of users assigned to a relation. So we're looking to implement an algorithm like the one described there (read with lock, add new relations and replace lock with existing lock as precondition)
j
so I'd use a lock relationship per resource, and have it represent a hash of the current state
then, when you're writing the updates, you'd hash them and use that as the new lock value, while checking and then deleting the old one
a
Alright thank you. I follow, but not sure why using a hash of current state is significant. For ex, if I use a uuid or increasing integer, I don't need to read all of the existing assigned users to figure out the new version value. Would that work or is there something I'm missing?
Hrm no I guess I do though, in order to know the current count
j
bingo
that's why I argue using a hash
it isn't strictly necessary if you can compute it based on another data source
but if you're reading everything anyway
might as well
a
It might be moot, but wouldn't it still work though, using another value?
(just trying to make sure I understand)
j
yes
you could use a UUID
but a hash has some nice properties
like, if two updates are occurring with the same change
then they'd result in the same state
minor benefit
a
yeah that's fair
i'm considering encoding the current number of assigned users in the lock, to avoid having to read all relations (which could be arbitrarily many)
e.g. write lock:somevalue_5 ... if i know max is 10 (another relation i think?), then i know if i add a new user relation while lock still == somevalue_5, i haven't violated the max
j
that works
a
Cool :). Thanks for talking it out. Per the original question – is there any difference from a scaling perspective if the resource ID is something broadly shared vs something unique? Like is the cache at a per relation level or is it possibly loading up some other relations for that resource eagerly (for example)?
j
cache is per problem
so resource + permission + subject
+ revision
a
i think that makes sense. so you're caching only what's necessary for those given inputs?
j
And any intermediate problems
a
Makes perfect sense. Thank you again!
3 Views
PreviousNext
Powered by