I will come back tomorrow...

okay. if you get blocked again,

zed relationship create

will return a string when the create is finished called a zedtoken

if you add

--revision "thatstring"

to the check command

it will use it to ensure consistency

jeah seems to have worked

so then i probably have a stupid question... i have to store that zedtoken in my DB right? to make sure next time i access the object i actually use the new permission... tho when i have a high concurrency api, and in the time between spicedb update & db update with zed token, another request already checks permission... how should i prevent that?

normally, you don't

it is considered an acceptable tradeoff to have some consistency lag in favor of caching

if you need to be absolutely certain at all times, you can issue a check with full consistency as an option, but then caching will never be used

in most real-world applications, having a few 10s of seconds of consistency lag is acceptable; the use of the zedtoken for the specific update is to prevent the scenario where you remove a permission, then put sensitive information into a resource

ah ok.. nice... thanks ^^

new question... imagine you have following schema:

definition user {}

definition package {
    relation owner: user
    permission write = owner
}

definition release {
    relation package: package
    permission write = package->write
}

and i have a relation

package:123#owner@user:123

and

release:123#package@package:123

that means i should have permission

release:123#write@user:123

if i now remove the former relation... then i should NOT have the permission

relase:123#write@user:123

anymore... so... when i did that change (removed the former relation), i should get a zedtoken... if i now just store it the packages db entry... and next time a request comes and wants to ask if user has permission to write onto release... it would not request the zedtoken of the package, yet... so may use old state which is not good... what is the best option to do that? i could also store the zed token into the release db entry, but then i have to do, two DB updates, ones for package and one for the release... is there a better option to do this?

When you are checking before a write you should always use full consistency.

and if you are removing the relation on

release

, then the zedtoken should be stored for the release row, not the package row

I'm not removing the relation packagerelease, im removing the relation packageuser

ah

> so may use old state which is not good... the point is, though, that unless "release" has sensitive or new information, using the old state temporarily isn't usually a bad thing

jeah but "what-if" there is sensitive information in release? (i'm a hobbyist trying to expand my knowledge here by working on a project)

if a release could have sensitive info after the removal of a permission on a higher level definition, you'd do as you said and write the new zedtoken to the package, and use that for all following checks

in that case you're deciding that not only is direct access risky, so is indirect, and so to cover all your bases, you'd always update the zedtoken at the top level and use it for checking to guarantee your permissions change is reflected before you update the sensitive content

or just use the "full consistency" option on your checks

but as stated earlier, that completely turns off caching, which can cause a performance hit

jeah makes sense... thanks ^^

just had an idea... depending on how often i would have to change the relation packageuser... could it make sense to simply check permission "fully_consistency" after my change, even tho i dont actually have to check the permission... just to force update permissions?

that won't prevent the cache from being used if another check is made without the consistency flag

oh it doesnt? I mean... wouldn't that full_consistency require a chache update to happen or is there some other magic going on?

the way the cache works is that SpiceDB picks a timestamp to use for the check; full consistency ensures that SpiceDB picks the latest timestamp

but every cache entry is stored with its timestamp

so if a followup check is made without a timestamp, SpiceDB might pick an earlier one

depending on what it has in its cache