but it sounds like you want fully isolated validation>?

We have 150-200 permissions, there's not chance I'll be able to sell to any dev that they have to create relationships to cover all cases for all permissions all in a single file, and without reusing any relationship in assertions (or do so and be bitten by coupling down the line) 😬 I suppose my point is that "comment" and "just make sure they don't overlap" doesn't really scale to many permissions and many engineers!

makes sense

I was just pointing out what we do

even if there were isolated validation sections though, it seems like you think a single file would still be unsustainable?

> even if there were isolated validation sections though, it seems like you think a single file would still be unsustainable? Yes, I'm trying to have one file per permission. I have a dummy script that adds the

schema

section before running

zed validate

, but it means I can't just upload these files to the playground which is a bit sad

I've been musing for some time how to make the testing experience more expansive, and was considering the idea of isolated validation sections

but still within a single file to make interacting with tooling easier and to make it so that a schema is always bundled with all its validation

the other option would be to have the

.zed

for the schema, and distinct validation test files, but loading that into the playground would be annoying

> but still within a single file to make interacting with tooling easier and to make it so that a schema is always bundled with all its validation I agree with the value of it, but I do think it quickly doesn't scale! > the other option would be to have the .zed for the schema, and distinct validation test files, but loading that into the playground would be annoying That's exactly what I'm doing indeed

Also, using the playground is nice, but it's also not ideal: it means we can't use our own editor with our shortcuts and everything (eg some of us use Vim mode in our editors)

yeah, that's where the LSP work will come in

@User want to open an issue to discuss improvements to the validation workflow?

allow a place for a proposal to develop on improvements

my primary concern about multiple files is that means we'll need some sort of reference or project system or file

> @User want to open an issue to discuss improvements to the validation workflow? Sure! As soon as I have a bit of time! > my primary concern about multiple files is that means we'll need some sort of reference or project system or file Agreed, I don't have a very satisfying solution in mind

where are you keeping your canonical schema right now?

in a

.zed

file, at the root of my repo

ok

How would you compare spicedb to keto?

@User keeping in mind I'm not completely 100% objective, SpiceDB is a logic-complete implementation of the Zanzibar paper (including full support for arrows, etc), along with improvements we've added such as Schema, a large amount of tooling and new APIs (e.g. lookup). Keto seems to be much earlier in its implementation, and last I checked, doesn't support the full range of Zanzibar operations

@User thank you, that was my impression also.

Just a heads up, I think the docs reg. recursive permissions are broken: https://docs.authzed.com/reference/schema-lang#recursive-permissions

furthermore also the

#

anchor seems to be broken 😉

thanks @User, will take a look

The garbage collection on my Postgres datastore is timing out with the default settings. I can tune the settings, but a few questions: First, the query seems to be

WITH rows AS (SELECT id FROM relation_tuple WHERE deleted_transaction <= $1) DELETE FROM relation_tuple WHERE id IN (SELECT id FROM rows);

. Why not

DELETE FROM relation_tuple WHERE deleted_transaction <= $1

? Second, there's no index on that table that PG can use for this query. PG will have to do a seq scan on the table, is there a reason behind the absence of index? In my case (20M relationships in database), such a seq scan takes 2 full minutes

the query is that way so we can batch it

instead of doing all the deletions as a single call