https://authzed.com logo
Join Discord
Powered by
Developing a Schema
# spicedb
t
Hi, I noticed that on https://authzed.com/docs/spicedb/modeling/developing-a-schema it states:
Copy code
This guide does not specify prefixes on its definitions.

If you intend to deploy these examples to an environment that uses prefixes, you'll need to place yourprefix/ in front of all definitions and references like so:

definition document { ... } -> definition yourprefix/document { ... }
Is there an example somewhere that uses prefixes? In a different context I'm considering modelling a larger domain with prefixes and wonder how that might work in SpiceDB, especially if they are deeper in terms of nesting. Can I have arbitrary nesting?
v
prefixes are solely used for the multi-tenant Authzed Serverless. If I'm not mistaken, in OSS SpiceDB / Dedicated it has no semantic meaning. I don't think you can have arbitrary nesting, but maybe @Joey knows from the top of your head
t
In the broader context, I'm considering having object types defined in a nested structure based on domains (which becomes a tree) and it would be nice if the object names would reflect that. I'm guessing there could be some naming hack in terms of special characters for the nesting in the name, I've considered using colons : but those are used in the syntax here. Any guidance here would be super helpful.
j
object names are your decision; you could use 
_
t
I was toying with things in the playground, I found I could replace names with 4 levels deep nesting using slashes. Now, that works in the playground... Any reason I should be worried about that not working in some other context?
so for example app/domain/iam/user instead of just user
seemed to work so long as I replaced object names consistently throughout the defintions, test relationships, assetions...
Yeah, underscores might be part of names already, but yes. Makes sense. I guess I'm wondering if doing actual nesting with slashes would surprise me in ways I'm not aware of yet (as a newbie to SpiceDB). I'm looking to represent a legacy system moving into a microservices architecture and moving authz decisions out of code. There may be ambiguous names, and I'd like to make them unambiguous by separating them into application domains. They would be DDD domains essentially, with teams and their services owning domains/sub-domains and users having access to those.
j
whatever works in playground will work on any non-serverless install
so that should work, assuming you don't hit object ID length limits
t
What is the length limit?
j
1024 currently
t
Cool. Thanks!
j
128 for the type name
t
OK, yeah that's something to be cognizant of for sure.
111 Views
PreviousNext
Powered by