Notably from startup I saw:

{
  "level": "error",
  "module": "pgx",
  "args": [],
  "err": "ERROR: relation \"metadata\" does not exist (SQLSTATE 42P01)",
  "pid": 1845518,
  "sql": "SELECT unique_id FROM metadata",
  "time": "2022-06-16T17:01:04Z",
  "message": "Query"
}

and from the schema write attempt:

{
  "level": "error",
  "module": "pgx",
  "args": [],
  "err": "ERROR: relation \"namespace_config\" does not exist (SQLSTATE 42P01)",
  "pid": 1845518,
  "sql": "SELECT serialized_config, timestamp FROM namespace_config",
  "time": "2022-06-16T17:06:28Z",
  "message": "Query"
}

did you run the

migrate

command?

Ah no I hadn't, it looks like I would need to exec into the docker container and then run the spicedb command in order to do that?

Hmm it doesn't seem like

sh

or

bash

is available for that image so I guess I just need to run

spicedb

locally on my machine

or have an init container do it

Ah yeah true. Okay I was able to get it working with local spicedb. Thanks for fielding my questions, much appreciated

i'm working with getting a grpc client written in clojure (protojure) working against spiceDB, and i'm running into problems with the connection closing down after a request or two. it's built directly on a jetty client (i.e. not using the official Java gRPC client) because the java client wants to be handed specific types that aren't implemented in the clojure code. my sense is that this is a combination of the behavior of this particular library and gRPC semantics, but i'm really not familiar with the latter beyond "it uses http2 so it can reuse connections." are there resources out there that give an overview of how i can expect gRPC connections to behave, and how i should write my code in terms of when it should attempt to create vs reuse a connection?

@yetitwo so long as you reuse the client, it should keep the connection open and reused for subsequent requests, but gRPC may have a default timeout after which the connection is closed. are you seeing it closed immediately?

its also possible that gRPC client in Java has different semantics by default

i'm seeing it closed after a ~few seconds saying "session closed"

which sounds like it might be an issue with the way this particular client was written, or a lack of clarity from the devs of the client on how it is intended to be used

and my sense is that gRPC is designed so that you would send potentially several requests over the same open HTTP2 connection, but that those connections aren't intended to be extremely long-lived (less than minutes)

Hi all, I am trying out spicedb/authzed and have a newbie question. What is the recommended way to develop and unit/integration test a schema? Running spicedb locally? Creating a test project in authzed and connecting to that during tests? Any ideas/examples appreciated.

Use serve-testing for testing against your schema

For the schema itself, it’s recommended to use the playground for development and then use the validate system in CI for validation

The playground is great and it is basically what I want to test on my tests, but I am looking for a way to write and source control test relationships. I will try the serve-testing.

zed validate

and the validate CI system

are for validating in CI

Yes, that is perfect, if I can run the same setup locally on my unit tests, then all done. I will try to spin up the same containers as the GHA does

you can use

zed

locally

zed validate file.yaml

will validate the playground downloaded file

jakemoshenko3085 I am still exploring

I've got a schema that looks something like this:

definition user {
  relation persona: user
}

definition thing {
  relation reader: user
  relation writer: user
  permission read: reader + writer
  permission write: writer
}

the "persona" notion is that a user may have personas which only have access to some subset of the things which the user can see. the concrete use case is a salesperson with access to many things showing a prospective customer what it looks like to be a user in the system with various levels of privilege. it seems like this model should suffice. however, one of my coworkers asked me whether it's possible to get a list of all personas with read access on a thing, and then get a list of all nonpersona users with read access on a thing. it''d be filtering on whether a given user has a persona relation pointing at it. is there a way to express this in a

ReadRelationships

request? if not, is there a better way of asking the question, or of modeling this such that that question is answerable? we could theoretically move the question outside of spicedb by having a naming convention for "persona" users vs normal users and then doing a string filter on the output of a Read request, but i'm wondering if there's another way of approaching it.

in the above a user's persona is another user?

the recommendation would be to define

persona

as its own type