https://authzed.com logo
quick question when using a lock
a

Alec Henninger

03/21/2023, 7:04 PM
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

Joey

03/21/2023, 7:16 PM
what are you intending to use the lock relationship for?
a

Alec Henninger

03/21/2023, 8:03 PM
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

Joey

03/21/2023, 8:06 PM
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

Alec Henninger

03/21/2023, 8:34 PM
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

Joey

03/21/2023, 8:37 PM
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

Alec Henninger

03/21/2023, 8:38 PM
It might be moot, but wouldn't it still work though, using another value?
(just trying to make sure I understand)
j

Joey

03/21/2023, 8:40 PM
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

Alec Henninger

03/21/2023, 8:41 PM
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

Joey

03/21/2023, 8:43 PM
that works
a

Alec Henninger

03/21/2023, 8:44 PM
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

Joey

03/21/2023, 8:48 PM
cache is per problem
so resource + permission + subject
+ revision
a

Alec Henninger

03/21/2023, 8:49 PM
i think that makes sense. so you're caching only what's necessary for those given inputs?
j

Joey

03/21/2023, 9:13 PM
And any intermediate problems
a

Alec Henninger

03/21/2023, 9:18 PM
Makes perfect sense. Thank you again!