You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Our use case I think is pretty standard ... we have both users and organizations. There is not a one to one mapping between the two. I.e. a user can belong to multiple organizations. The vast majority of queries will use the organization as the tenantId .. however, there will be certainly queries against some tables where there is both the userId AND the tenantId .. where we want to query only against the userId.
For example, to get the list of organizations a user belongs to -- there is a user_organization table .. when we query against that table we do not want to auto inject the tenantId to restrict it ..
So how can we "fine" tune the auto injection!?
BTW -- these tables have been around for 15 years with a LOT of supporting code behind it, so it's not as simple as just renaming the column in the tables we don't want to autoinject.. :)
Cheers!
The text was updated successfully, but these errors were encountered:
Our use case I think is pretty standard ... we have both users and organizations. There is not a one to one mapping between the two. I.e. a user can belong to multiple organizations. The vast majority of queries will use the organization as the tenantId .. however, there will be certainly queries against some tables where there is both the userId AND the tenantId .. where we want to query only against the userId.
For example, to get the list of organizations a user belongs to -- there is a user_organization table .. when we query against that table we do not want to auto inject the tenantId to restrict it ..
So how can we "fine" tune the auto injection!?
BTW -- these tables have been around for 15 years with a LOT of supporting code behind it, so it's not as simple as just renaming the column in the tables we don't want to autoinject.. :)
Cheers!
The text was updated successfully, but these errors were encountered: