One question for ya’ll today 🙂 thanks for all your help this week as I continue to throw things at you. For this example let’s say I’ve got a bunch of Profiles in my system and I can view them based on the existence of some Connection model (connects me and that profile). So you might have something like a User table, a Profile table and then a Connection (light join table between a User + Profile). Ultimately I'd love for things to be performant + do well when query planning. This information can either live on the Principal or the Resource. The Principal feels more natural, but would require passing all my connections in, which doesn’t feel like it’s going to scale too well. You could make a new resource attribute (R.attr.hasConnection) , that’s a bit principal aware. You could lean on the database here and just check for the existence of some thing. On the query side you want to be able to map this variable to a prisma condition like the below, but I’m not sure if there’s a good way to do this?

some: {
 connection: { id: R.id, user: P.id }
}

The latest Prisma adapter handles relations Prisma Schema Test Policy Test case for some

You're too fast Alex 🙂 This definitely helps! If I follow, in the example there if

ownedBy

becomes really large, aren't you still potentially passing a lot of extra information into the

checkResource

calls? Where as the information you might care about is "is the principal an owner?"

If you are authorizing just a single instance (rather than a listing page) and using check resource then indeed if the list is large, then the recommended optimisation would be to just have an

isOwner

boolean as an attribute on the resource

So then do I need to balance/handle both to support both the listing/check calls well?

in this case i would create two ‘actions’ in the policy. one for ‘list’ which is used on the

/list

and the query plan one for ‘view’ which is used on

/list/:id

Interesting, but makes sense. I'll do some thinking on that and think about the lift of splitting the two out. Right now, all of our policies are written in a way where we can check + plan. Sounds like we'll have to let go of that at some point.

In most cases keeping it as one works but if you are worried about the size of the owners list then spilting out helps.

Might be someone else's problem in a year 😛

Can you expand on that a bit?

Oh just this https://cerboscommunity.slack.com/archives/C02A364JYMQ/p1664317145774149?thread_ts=1664305581.527359&cid=C02A364JYMQ

Currently yes. Open to ideas on how to improve it!

This would be useful on my end, can look at the orm-prisma library as well to see how you might extend. Supporting it feels like it should be ~fairly straightforward? You could specify something like ['join_1', 'join_2'] to describe the relationship. Field would remain the same.

Hadn’t thought of using a list like that - nice.