You can't read all relationships, you at least need to specify the object type, and as your db grows you will need to filter even further to avoid timeouts

It will be validated in some ways by default, e.g. it has to be self-consistent and you won't be able to remove relations that still contain data. It won't do the full test relationships, expected relations validation that zed and the playground do though. My suggestion would be to do

zed validate

in CI (as well as some other custom tests using your code and the

spicedb testserver

), and then once merged just use the API.

and if you use GitHub actions for CI/CD, we have an Action to run the validation too

We are using AWS for repository and deployment. We want to add validation and writing the schema to the AWS pipeline, actually.

yeah, using

zed validate

is the right call here. you could even use the Dockerized image for it, if you like

what do you mean all the modules will have the same ID?

this is likely a stupid question but what exactly are the 3 dots for in relations?

they mean that you're referring to a subject directly, rather than a relation defined in it. You shouldn't see the three dots anywhere besides internal logic. Where do you see it?

@Joey

ah, yeah

that's from before we made them optional

ah, okay. Cool.

so just not specify them

I assumed it was the subject relation but it wasn't showing up in the table view. What is that field?

it is the optional subject relation

but we found requiring everyone to specify

...

was too verbose

so when we released API V1

we just made it optional in the API, unless you want to refer to a concrete subject relation

Gotcha. Kinda. Not sure I quite follow the need to refer to a subject directly rather than a relation.

most of the time you'll refer to a subject "directly"

I appreciate your help once again 🙂

so for example:

definition user {}

definition resource {
  relation viewer: user
  permission view = viewer
}

in the above example, you're saying the

user

is directly a

viewer

of the resource

vs

there, you say any

member

of

team

is a

viewer

all we did is make it so you can do

relation viewer: user

instead of

relation viewer: user#...

helps with readability

and

...

isn't obvious

so subject relation would be team#member?