Postgres, ha

yeah, it's basically a placeholder for when a subject doesn't define an

OptionalRelation

we left it in at the datastore layer because it's safer than leaving it the empty type and then trying to distinguish between missing data and the empty

OptionalRelation

we may end up removing it one day anyway

So since our app data is also in postgres, I'm experimenting with database triggers to keep app data and spicedb data in sync. Just wanted to make sure I wasn't missing anything with the

...

but it sounds like I can just safely have the trigger fill

userset_relation

with

...

in most cases.

interesting!

are you also synthesizing entries in the transactions table?

Yeah, I'm doing an insert on the transactions table returning the id

are you also synthesizing zedtokens?

I had not yet realized I might need to

it's somewhat use-case dependent

I confess I haven't grokked those yet.

if you're planning to always use fully-consistent or best-effort as your consistency strategy you won't need to

That is the hope with triggers.

to use fully-consistent?

yeah, have our spicedb data be ACID with our app writes

I talk a little bit about the performance strategies in Zanzibar here:

you can see how zedtokens/zookies are used to increase cache hit rate without sacrificing consistency

How likely to change is the magic number 9223372036854775807 in

deleted_transaction

? Just wanting to get an idea of how much work will be involved in maintaining postgres triggers that hit the

spicedb

schema if there's ever a breaking update.

very unlikely to change, that is the largest signed 64-bit int value

it used to be the largest unsigned int, but postgres didn't like that

hi folks, one question regarding the use of zookies, if do a check with a zookie but that zookie is not (yet) know due to eventual consistence model, does the check fail or is there some internal mechanism to kind of wait until that original transaction is known?

@User if you're creating the Zookie/ZedToken via an API call, then it is by definition known, and so the system will always be able to handle it (unless you ask for

at_snapshot

and the data has been GCed). If the data is not cached, the system will go to the datastore and ask for it.

If you do ask for

at_snapshot

and the data in the ZedToken has been GCed, then you will receive an error

which is why we recommend not using

at_snapshot

unless you need the exact data at that time

Would it make sense to be able to send some relation tuples with a

Check

call which would - in that request only - be considered as existent? Sort of a mix of the in-memory and persistent storages.

that's a really interesting idea, can you talk about your use cases for wanting it?

my normal reaction would be: that will break caching! but if you can commit to sending the same data each time, we can just hash it into the cache key