> assuming the schema update has had time to be replicated before your check which it might not

the postgres datastore also uses Postgres's internal MVCC bookkeeping for transactions

its possible that the data replication is modifying that somehow

Hey 👋 Just ran a

brew upgrade

after some time, and saw that spiceDB gets updated to 1.22.0-RC2 - is this expected behaviour? I would've guessed it only gets updated to latest stable 🙂 But maybe I misconfigured it?

additional note: it tries to upgrade to the RC, but fails with a 404 as the file is not found.

I don't think that's intended, no

We recently started doing RCs, so I think our release scripts haven't been adjusted

@jzelinskie ☝️

Yeah, our release script is shipping RCs everywhere. Honestly, we wanted to see how it went and collect feedback from folks.

Sorry -- it should work now -- the pipeline also turns releases back into drafts sometimes after they're cut

Hi folks! I wanted to run this idea by you to see if it’s a feasible option. We have an app that stores its data in a mysql database. In order to use SpiceDB, we need to replicate some of the columns from this db into SpiceDB’s datastore. I wonder if it is possible, rather than replicating the data, run SpiceDB on top of this existing database, without changing the schema of the existing data, just by adding a (possibly readonly) datastore connector? Say we have a mapping that tells us relation “s r o” can be fetched through “select x, y from table t”. Note that the existing database doesn’t not do MVCC, but we “last_updated” timestamp on all row that could help. We may need to add some tables to store the schema and caveats but my question here is specifically about relations. Thoughts?

possible in theory

but the consistency guarantees will be an issue

you'll need to make sure if a row is updated there is a way to retrieve the "older" version of the row

This is the part I don't understand! What exactly do we lose if we always use the latest version? For how long do we need to keep the version history? Is that only for the duration of ztokens? Then if we don't have any history, will it be inconsistent just for the duration of ztokens?

it has to be kept for the duration of what we call the "quantization window" IF you're not using

at_exact_snapshot

consistency (which some people do, but many do not)

basically: when an API call is made to SpiceDB and

minimize_latency

is used, SpiceDB will pick a revision that is slightly older than "now", to efficiently use caches

but, in order to do that, it needs to be able to query at that older revision

which means there needs to be some way to ask the database for a view of the world at that older time

that window is usually 5-10s

but it is necessary

if you use

at_exact_snapshot

for anything, on the other hand, you need to be able to return data for it over a longer period

most default installs have that window as 24h

as a complete outsider, we've had pretty good luck treating the spicedb datastore as a black box

the more you try to interact with it at the database level the worse a time you're going to have

yeah, that's generally the recommendation

especially since we reserve the right to (and have) change the internal representation

it should also be noted that this may be possible if you use something like CRDB, which does provide "at specific time" querying

Is there a document that explain the consistency model in depth? I want to know a bit about the internals as well. Or I just need to read the source?

there is an overview one here: https://authzed.com/docs/reference/api-consistency