Thank you, what is the ZedToken in CRDB? What is the scope of the revision tracking?

same as spanner

apologies; its on the object type

Got it, so the uncertainty depends on the underline CRDB. Thanks!

well, let me ask this: what, exactly, are you trying to bound re:uncertainty?

The message is still apearing, the schema definition is done using this string { "schema": "definition user {} definition document { relation reader: user \n}" }

how are you constructing that JSON for the update?

Manually, in postman

ah

its

object_type

not

objectType

same with the ID

ok.. now it is working... thanks a lot!!!

I am thinking the uncertainty of the updates ordering across different resources.

ordering across different resources shouldn't have any effects unless they are dependent, in which case you can make that explicit by doing the updates as one transaction

can you give an example where you might be concerned?

Thanks. You answered my question. My concern is basically ACL updates on two resources in two regions that is in one transaction.

if it is one transaction and you're using a multi-region datastore like spanner or CRDB, then the datastore handles ensuring the transaction either commits as a unit or does not

Thank you, that answers my question.

BTW, I not too long ago worked on GCP IAM. Super excited to see an open source version of Zanzibar. Especially directly facing the consistency challenges without Spanner.

we have a great blog post about those challenges: https://authzed.com/blog/prevent-newenemy-cockroachdb/

Awesome. Thanks!

Hi All, We have the following scenario: We have following resources: order(which has a location attribute), bill ( which has a location attribute) We have the following contexts: location ( a location could be referenced in several administrative regions), administrative_region We have this authz model: user, role(clerk, supervisor, etc...), permission and context (location or administrative region) · A role can have several permission sets: order_read, order_write, bill_read, bill_write ( so the relationship would be a kind of role:clerk has permission:order_read) · Then, we grant a specific role to a user, in a specific location or administrative region ( so the relationship would be user:elisa member of role:clerk in location:france) Then we would need to check if: user:elisa has order_read permission on location:france user:elisa has order_read permission on administrative_region:europe In a similar question, I got this answer: definition user {} definition region { relation sales_manager: user relation sales_clerk: user relation accountant: user ... permission order_read = sales_manager + accountant } If this a good approach? I mean, if my app has hundreds or permissions and roles, having all in the same definition? And in case that multi tenancy is required, should it be hardcoded on the permission defintion (tenant1_order_read, tenant2_order_read)?

I have a question about v1.14.0: - It includes migrations for the Postgres datastore, which are deleting the

created_transaction

column and adding a new

created_xid

(as well as other things). - v1.13.0 relies on

created_transaction

, v1.14.0 relies on

created_xid

Doesn't that cause backward/forward compatibility issues? - If the migration is ran as a pre-update hook, SpiceDB will be failing while

created_transaction

doesn't exist anymore but v1.13.0 is still running - If the migration is ran as a post-update hook, SpiceDB will be failing while

created_xid

doesn't exist yet but v1.14.0 is already running

If I need to deploy one schema in multiple permission system , I need to update the schema file it self. as example here here the permission sytem is kylelobosb_ecommerce . For any other permission system , I need rename this part.

definition kylelobosb_ecommerce/user {}

Any suggestion to avoid this ?

There are a series of steps to run through the migrations without downtime, we plan to update the release notes with a detailed guide but roughly (all steps are with v1.14.0 of spicedb): - run

spicedb migrate add-xid-columns

- update spicedb to 1.14 with

--datastore-migration-phase=write-both-read-old

- run

spicedb migrate add-xid-constraints

- update spicedb with the flag

--datastore-migration-phase=write-both-read-new

- run

spicedb migrate drop-id-constraints

- update spicedb to remove the

--datastore-migration-phase

flag the next release of the operator will support walking through these phases automatically, but those are the manual steps

hello, I upgraded SpiceDB from v1.13.0 to v.14.0. after that, I ran

spicedb migrate head

and

zed schema write

- both failed for me. Full error output logs are below:

$ docker exec * spicedb migrate head \ > --datastore-engine postgres \ > --datastore-conn-uri "postgres://***:***@staging-db.*.us-east-1.rds.amazonaws.com:5432/spicedb" {"level":"info","format":"auto","log_level":"info","provider":"zerolog","async":false,"tme":"2022-11-03T14:25:19Z","message":"configured logging"} ... {"level":"info","from":"add-ns-config-id","to":"add-caveats","time":"2022-11-03T14:25:22Z","message":"migrating"} {"level":"info","from":"add-caveats","to":"add-xid-columns","time":"2022-11-03T14:25:22Z","message":"migrating"} {"level":"error","error":"unable to migrate to

head

revision: error executing migration `add-xid-columns`: ERROR: type \"xid8\" does not exist (SQLSTATE 42704)","time":"2022-11-03T14:25:22Z","message":"terminated with errors"} ```

and

$ zed schema write schema.zed
10:25AM FTL failed to write schema error="rpc error: code = Unknown desc = unable to find revision: ERROR: column \"xid\" does not exist (SQLSTATE 42703)"

Ideas/suggestions?

you need to be running postgres 13+