get_user_courses_bycap() replaces get_courses_bycap_fromsess().
Using a combination of in-DB enrolments and in-session capability
checks, we narrow down the courses we fetch from the DB for checking.
This patch adds a small DB query, and has has a moderate impact on
the timings observable on my laptop (~300ms?), but reduces
*significantly* the bandwidth used, which in cluster environments
with frontends separate from backends has a serious impact.
get_my_courses() goes from a bazillion queries (500 in some sample
cases) to 1 for the logged-in user, and 4 for a non-logged-in user.
One of those queries brings a *lot* of data across (all rows from
mdl_course) so there is room for serious optimisation.
However, this clocks at ~300 ms on my laptop, costly, but not
the end of the world. If your PHP-DB link has bandwidth probs
it might be a problem.
A few important changes to get_my_courses()
- (Compat ALERT!) the default fields are less than before --
(will be followed by patches that fix the callers!) our defaults
had grown to quite a bit because of the crazy caching scheme it had
- the $fields parameter is to name _additional_ fields you need, and
ideally wants them passed as an array. Will cope with old-style
strings too.
- the returned courses have an extra property "context" that is
a fully valid context object, so if the caller needs to perform
further accesslib checks, we save a query per course down the road
The work is done in the newfangled get_courses_bycap_fromsess()
which is brute-force but fast. I'm sure we can optimise the common
cases a lot in it if we try. It'd be worthwhile to
- reduce the rows we grab - that's really boneheaded
- if we copy and tweak the logic of has_cap_fromsess() in it
it can be made even faster
The main thing here is that overrides in subcontexts are
now read correctly (and still cheaply) into the access array.
Also
- introducing aggr_roles_fromsess() with gives you a list of
the relevant roles that affect the user in this context
- we clear out $USER->access on login/logout
- get_user_access_bycontext() gets a few optimisations too...
Changes around load_user_capability() and has_capability() to make
the default role fallbacks and guest/nonloggedin roles work.
This commit also introduces the concept of having a magic
context next to the root context in $USER->access[ra], as
$USER->access[ra][/1] = 1 (admin roleid)
$USER->access[ra][/1:def] = 7 (loggedinuser roleid)
and has_cap_fromsess() now checks for that magic context
as well.
With this commit, the new has_capability works for the logged
in user correctly.
- load_all_capabilities() no longer calls load_user_capability()!
6K dbqueries less on login... ;-)
- When delving into a context we haven't loaded yet, we call
get_user_access_bycontext()
- Introduce: get_user_access_bycontext()
- Several fixes in get_user_access_sitewide()
(renamed from get_user_sitewide_access())
- Fixes in has_cap_fromsess()
- Introduce access_insess() to check if we have to call
get_user_access_bycontext() for the context
- has_capability() renamed has_capability_old() and we fallback
when we cannot answer the question
- has_capability() works great for the course-and-above contexts
for the logged in user - does not touch the DB
- works based on $USER->access which has a pretty compact view
of the user's access rights...
TODO:
- deal with contexts below the course - here we need to
trigger the role-assignment and role-defs load when needed
- deal with "other" contexts that hang from the system context
- deal with global roleswitch, local roleswitch
This function carefully fetches all the data needed to
handle site/category/course access for a given user
as cheaply as possible.
It currently takes 3 db queries.
Using context.path, now get_child_contexts...
- always takes 1 query
- populated the context_cache
- returns full records
- when called with an category, it won't
recurse into the children of courses
Also
- All callers in accesslib changed to the new
calling convention
A normal course page with a std blocks and a few
activities sees around 100 queries less with this patch.
Note: this commit is slightly different on HEAD/19 and on
MOODLE_18_STABLE, as groups-related tables have changed.
- On postgres query time drops from ~600ms to ~35ms in some
instances, in other instances performance is around the same
as old the implementation.
Author: Matt Clarkson <mattc@catalyst.net.nz>
