quick question when using a lock
a
Alec Henninger
03/21/2023, 7:04 PMquick 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 PMwhat are you intending to use the lock relationship for?
a
Alec Henninger
03/21/2023, 8:03 PMSame 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 PMso 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 PMAlright 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 PMbingo
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 PMIt 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 PMyes
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 PMyeah 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 PMthat works
a
Alec Henninger
03/21/2023, 8:44 PMCool :). 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 PMcache is per problem
so resource + permission + subject
+ revision
a
Alec Henninger
03/21/2023, 8:49 PMi think that makes sense. so you're caching only what's necessary for those given inputs?
j
Joey
03/21/2023, 9:13 PMAnd any intermediate problems
a
Alec Henninger
03/21/2023, 9:18 PMMakes perfect sense. Thank you again!