if you need to track on a per team basis, you'd need to check for the team

Hey all, I'm looking into code-generation for a given schema. Before I start to write my own schema parser I was wondering if there is a) already a similar solution existing or b) a package for a parser. Ideally there would some machine-readable intermediate representation such as JSON.

this one, right: https://github.com/authzed/spicedb/tree/main/pkg/schemadsl ?

That would just spit out an AST, right? Looking at: https://cs.github.com/authzed/spicedb/blob/38bd780f1d9b6924ec42efd0114c9e7da6355337/pkg/schemadsl/compiler/compiler.go?q=parser.Parse#L44

Yep

A long shot: There doesn't happen to be some documentation reg. the AST?

ok, I see, the node type description is somewhat helpful 🙂 https://cs.github.com/authzed/spicedb/blob/38bd780f1d9b6924ec42efd0114c9e7da6355337/pkg/schemadsl/dslshape/dslshape.go#L7 That should at least get me started

Keep in mind that this definition will evolve as we extend the schema DSL

Also, we have some vague plans for code generation, so we would love to get your requirements and use cases documented if possible

Great! I'll try to track my requirements. Probably I'll fork the CLI and implement a command there to walk the AST or similar.

No need to fork the CLI, you can just bring it in as a library

Here a rough draft of the use-cases I can see valuable for us:

UseCase.1: Machine-readable file containing the name of objects as well as the name of possible relationships and permissions.

> allows generating the necessary string constants and can do basic validation of queries client-side



UseCase.2: Machine-readable file containing the name of objects as well as the name and type of possible relationships as well as the name of permissions.

> Allows generating type-safe builders for relationships. Helps creating/removing relationships.



UseCase.3: Machine-readable file containing the name of objects as well as the name and type of possible relationships. Furthermore, have all the predicate information for permissions.

> Allows generating type-safe code to create relationships and check permissions. E.g. generate type-safe methods for things such as `can<Permission><Object>(<Object>, <Subject>) which would then be canWriteDocument(Document d, User u) whereas Document and User are actual generated types and the method would check the document:<id>#write@user:<id> permission

with mysql, duplicate entries cause failures unlike with postgres where they are ignored. is this intentional?

here a proof of concept: https://github.com/authzed/spicedb/pull/657 Is that roughly what you had in mind?

i was actually thinking more about the actual language level library generation

i've toyed around with some well types clients a few times in the past, in go and in python

it had everything you talked about plus more things like guiding you not to do a permission check if your subject type wasn't in the transitive closure of types that your starting resource could be associated with

neat! For a very first step I think a stable representation of the schema would already be valuable. That allows everybody to implement clients as they like.

The current representation seems to be the protos the compiler spits out, which are not exactly easy to manage 🙂

understood

Probably a JSON would be the one that is easiest to read for everybody, but open for other representations.

@thomas.richner the ideal would be something that code generators exist for

but I haven't found any such "generate ORM in a standard way" format

There's https://kythe.io/, but I don't think there is a lot of tools around to actually make use of it...

Anyways, some basic export for schema information would be very valuable and even if it's only the names for now. I don't think you can build a one-size-fits-all client library for each language.

I'm using Postgres

mind filing an issue for us to add GC of the namespace_config table as well?

Done: https://github.com/authzed/spicedb/issues/660

hey! is there a specific reason that 128 bytes is the max length for object, subject, and relation values?

We had to set a limit and that seemed like a good one from a computer science perspective