Are there translations of the examples in the playground to a more modern style?

Are there performance implications if one chooses to depend on a relation instead?

No

Is it possible to write the example schemas while complying with that lint? Like the User Defined role one. Is this just a lint one should be comfortable ignoring?

yeah, that'd be my take. you typically want to use permissions instead of relations so that you can change the definition of the permission without needing to do a data migration, but if you're using e.g. the google cloud iam schema, and it's yelling about the arrows to the

role

relations, that's a structure that you're probably not going to change for the life of the schema, so adding intermediate permissions is just additional verbosity

which makes me think that we should probably have some mechanism to suppress lint warnings via comments or something

i added an issue for that

thanks for the explanation!

Hi Guys 🙂 I am quite new in spicedb and have some questions regarding lookup resources. In my system, there are about 1,5 million users. 99% of these have access to just a few number of resources (documents, other users, etc.), for them lookup resources works fine. But I have a few users (the admins), which can access all or nearly all resources in my database. These users cause a lot of trouble when calling lookup resources to often (the calls run in timeouts and are slowing down the db so much by using all its cpu, that all other calls are affected by that). I already read through some discord conversations and saw that I am not the only one with this problem (https://github.com/authzed/spicedb/issues/1317 and https://authzed.com/docs/spicedb/modeling/protecting-a-list-endpoint#the-problem-statement). 1.) Does the limit in the endpoint have any effect on performance? I tried to log the produced sqls (which are taking super long to run in my postgres db because the number of affected rows is so huge) and there is no limit in these, is it correct to assume that using a limit of 10 instead of 100 will not make a huge difference for the db? 2.) At the moment, we are blocking away lookup resource calls from users with too powerful permissions. Besides of bulk checking random resources until we find enough resources the user has access to, MaterializeApi could be a solution for us. Are there any numbers regarding performance for this? Is it performant enough for a system with so many users and millions of resources? We are a little scared to use this because of money and early access 😅 3.) Would a different db (for example cockroach db instead of postgres) make a difference? Thank you so much for your good work!

Hi is there a way to use "." and "@" in SubjectID? I see regex error: "invalid ObjectReference.ObjectId: value does not match regex pattern \"^(([a-zA-Z0-9/_|\\\\-=+]{1,})|\\\\*)$\"" is this hardcoded and can not be changed?

Hi everyone, if I only need to check one permission, is there any meaningful performance difference between calling the regular permission check API vs using the bulk permission check API?

No

Hey we are trying to use cursor and limit in read relationship for pagination but we get the same results all the time. Is there something we are missing?

Hey, currently struggling/trying to wrap my head around the "Dual Write Problem" https://authzed.com/blog/the-dual-write-problem Hypothetically speaking, if i were to embed spicedb in my go app, could i not pass it a datastore (postgres in my case) transaction handle, and this way technically avoid the problem altogether? I would be fine embedding spicedb, since i really don't see another way to be truly consistent between writes to otherwise separate systems. Context would be an IAM system where i would want atomic updates in both a regular database/event log + spicedb.

no; SpiceDB explicitly does not support passing transaction handles across the wire

this would be in the same process (+ same database connection)

I'm aware, but the SpiceDB API is designed for use via gRPC

and SpiceDB manages its own DB connections as well

it would be a fairly large lift to support taking in an external DB txn

its doable, but its not easy

so this is a non-starter, even if i were to try to contribute a solution?

i see, thats fair, thanks for the quick heads-up

no, if you can find a good solution, we'd likely accept it

but I suspect its going to require some significant changes

yep i'll take a peek but i assume it will really be too much to think about

there is an existing txn construct in the PG datastore driver

and you could add a function to construct one for a given connection

but

you'll also need to add the validation that currently occurs in services/v1/relationships.go in front of any write calls

lest you accidentally write invalid rels