is there a typical pattern/approach for ensuring relations that act as a hierarchy of roles (i.e much of the examples in the docs - editor, reader, viewer, etc) don't overlap? e.g a user doesn't get assigned both viewer and editor relations. realize this can be enforced through application logic or preconditions, but from what I can tell doing so requires duplicating your schema into your code to add some more metadata (i.e these 4 relations are roles, always add a precondition when assigning from this set). I've ended up naming all "role-like" relations prefixed with roles (e.g role_viewer, role_editor). is that pretty much the standard approach? I guess what I find unsatisfying about this is that there's some implicit metadata about the intent of your schema that you can't really encode into it. I almost would want like a @metadata.relation_type("role") concept or something

yeah, that's the standard approach. not every system treats roles the same way - some treat roles as additive rather than mutually exclusive, so we leave that up to the user to define their business logic around it.

yeah makes sense. the ability to define unique constraints at the schema level would be sick but i know something something CAP theorem

we've talked about the idea of enforcing 1-m relationships in the schema (because otherwise everything is m2m) and this seems like it could be in a similar neighborhood

yeah i think so, provided you could define it across multiple relations, eg

relation viewer: user
relation editor: user
constraint one2many = [viewer, editor]

makes sense. i'll see what comes out of our discussions