print_course() can now recognise a $course object that already has a
$course->context obj and a $course->managers array, which means that
there will be no DB access triggered by print_course().
(Backwards compat is retained so it still works the old way for
callers that get a single course printed anyway (during enrolment
for example.)
And print_courses() now uses get_courses_wmanagers(), and passes the
returned $course objects to print_course().
With this patch, a homepage listing 9 courses (with varying numbers of
teachers) sheds 63 DB queries (88 to 25). A course listing page with
3 courses sheds 9 (33 to 24).
On a single server overall time spent serving the homepage is reduced just
a little bit (262ms to 238ms) -- on a clustered environment, less DB queries
mean much lower latency and DB costs.
move_courses() now calls content_moved() which will take care of any
accesslib-required changes. And introducing move_category() which
also calls content_moved() when needed.
Combined with the path creation in create_context() we can now create
a course, enter and edit it immediately. Amazing.
Like - 21st century technology.
Manually enrolling and unenrolling self, and other users should
transparently set the context dirty. So walk all callers to
role_assign() and role_unassign() and mark the context dirty
where appropriate.
OTOH, most automated-backend enrol/unenrol mechanisms should not.
The backend lookups that happen when you login are well covered
by the login/enrolment process, and don't need to be marked dirty.
This patch saves 1600 context lookups on a 1600 course category. rcache
does help a bit with small categories, but on large setups, this is
not sustainable.
And it's not needed either. We have the data right at our fingertips.
Just get it when it's cheap...
Implemented all the relevant checks for role_switch().
accesslib's role_switch() doesn't do any UI-related checks any more,
being a backend lib call. These belong here.
Move the fixups for orphan courses to the newly minted
fix_coursecategory_orphans() -- and optimise it to take only 1 dbquery for
the common case.
If we do find lots of orphans, we issue 2 updates per orphan.
This cuts down dbqueries drastically - we used to have 2x the number of
courses in the site.
