Accessible_query with NoSQL adapters

[Alan Etkin]

Would it be possible to implement a conditional mechanism without using joins for supporting Auth.accessible_query with NoSQL adapters? It's a very useful tool but it is not available in GAE, MongoDB, etc. This would save the need for implementing custom methods for filtering queries using rbac with those backends.

[Niphlod]

well, you should have for every record on mongo a copy of groups, membership and auth_user if you want to do that "in one shot".
The other way is having a transaction scanning groups, membership and auth_user and cross-reference it with the "FK" of your table....

[Alan Etkin]

> well, you should have for every record on mongo a copy of groups, membership and
> auth_user if you want to do that "in one shot".

Seems like it involves a lot of extra data stored and also possible sync problems, i.e. reading old rbac information

> The other way is having a transaction scanning groups, membership and auth_user and

> cross-reference it with the "FK" of your table....

This one looks like a better approach. I suppose it means adding actual db queries before performing the query to filter, with a considerable increase of server usage for each filter.

[Niphlod]

Unfortunately with no joins either you store within your record the relevant FK object and "update" them as soon as the FK changes, or you have to resort to fetching every "joined table" in a separate step.
Wouldn't know about concurrency issues, but for an "accessible query" with no joins basically you have to fire at least 3 queries (or 4, depending on the auth_user records being available yet, e.g. in a session)

- membership
- permission
- end table

with the everybody_group_id logic, probably other 2 queries.

[Alan Etkin]

> - membership
> - permission
> - end table

> with the everybody_group_id logic, probably other 2 queries.

Now I understand why there's no accessible_query for NoSQL, not even in the roadmap. No user would accept making 4 or 5 db queries for filtering rows in a single request. This may work in a prototype with a couple of records, but would take a lot of resources with thousands of records in production.
I guess the only alternative is writing rbac data on each record with an optional field factory when creating auth (for an implementation in the Auth class), but It is a partial solution. It would not solve handling custom rights because, AFAIK, you would need one field for each permission type ("read", "update", "custom", ...) and also it seems a lot stuff for implementing a single rbac feature.

[Niphlod]

please do remember that most of the speedup between rdbms and nosql (yes, I'm over-generalizing, but I'm going to state a simple core-concept) is due to the lack of features like this.
While a mongodb for storing incremental updates is probably a better tool for the job, it's not for complex relations handling (you have to code your own).