This thread looks to be a little on the old side and therefore may no longer be relevant. Please see if there is a newer thread on the subject and ensure you're using the most recent build of any software if your question regards a particular product.
This thread has been locked and is no longer accepting new posts, if you have a question regarding this topic please email us at support@mindscape.co.nz
|
Hello, I'm trying to optimize my application. At this stage I'm performing numerous requests to filter entities based on whether a user has access to them. I'd appreciate any help to reduce the number of queries. Here is a simplified class model that represents my entities. Assume I have all the necessary attributes etc to make this usable by LightSpeed.
In essence, a user can belong to one or more accounts through the role they play in the account. A role can be something like "Administrator", "Member", "Guest". An administrator can define an access role that an "Administrator" has "read", "write", "delete" rights on a specific entity, while a "Member" only has access to "Read" access. This model allows administrators to create their own roles and assign users to those roles, similar to ACL security. Now when a user requests access to an say an instance of Entity1, I first check to see if the user is the owner, if so, assume they have full access. Then I perform several queries to determine whether the user belongs to a role that has the right to access that instance of Entity1. The method looks similar to this:
This results in a number of queries. My gut tels me it can be optimized. If I didn't use LightSpeed, I could have written it as follows:
However, LightSpeed reports that "Any" isn't supported in a query like this. Is there a way I can rewrite the query so that it is supported by Lightspeed and to limit the number of requests to database? Thanks, Werner |
|
|
Hi Werner, If I am thinking about this correctly you may be able to express this using joins, e.g. something like
I suspect some of those look like they might be ThroughAssociations so you would probably have a few more joins involved :) Another approach you could look at is if the set of access rules is manageable you could look at caching this and then filtering against that client side in your method after you have loaded the unfiltered set of candidates. e.g. Find all AccessRules from the cached set that relate to the loaded entity and then perform the .Any() filtering against that set to validate that at least one access rule would be satisfied.
|
|
|
Thanks Jeremy, I'll be looking to see whether caching may actually simplify the query and improve its performance. |
|