The function sql_fullname had the same documentation as the function sql_ilike, which was not correct. Now updated to reflect what the function
actually does.
Author: Luke Hudson <luke@catalyst.net.nz>
get_courses_page() uses get_records_sql() which means that it will actually
break if the first field requested isn't c.id. This in turn means that
the DISTINCT is not needed at all.
So let's go fast again!
courses would be invisible if they were within a hidden category.
However, the old behaviour was useful in many instances, so I've added
a $CFG->coursesinhiddencategoriesarehidden that will return to that old
behaviour if required.
get_records etc are not inefficient if used correctly, and result in MUCH
more readable code that get_recordset does.
I'm already starting to see code being submitted that takes these
instructions literally and it looks like Java. :-(
require_login seems to be the best place to capture this, however
I'm sure there are a few little places where it won't work.
We need to hunt these places down and fix them, because I would
like to rely on COURSEID and remove all the "global $course" hacks
that are floating around.
Probably later we need the full object $COURSE as well (to match $SITE)
Previously we were literally doing hundreds of database queries, now it's
very much faster.
This makes the API slightly more complicated, but it's definitely worth it!
Each module should implement modname_print_overview, which takes an array of courses
and an array to fill up indexed by [$courseid]['modname'] for the controller to loop through and print.
Each module should LIMIT the number of queries to use, all module instances can be fetched
with the new function get_all_instances_in_courses which is the same as get_all_instances_in_course
but takes an array of courses to fetch the instances for. This means there is no need to loop
over the courses array and fetch the instances for each course (dramatically cutting down the number of queries!)
(instead of the first, non-cached, invocation). Also, modified one
condition with no sense now. Needs testing (specially from PostgreSQL,
although it should work and the bug would be solved.
(http://moodle.org/bugs/bug.php?op=show&bugid=4583)
get_recordset* functions, instead of duplicating code.
Note: I've replaced the @deprecated tokens in phpdoc with an indication
that the get_records* calls are valid as convenience calls. The
get_recordset*() calls should be considered for performance and memory
footprint, but are not mandatory.
In a sense, deprecating get_records*() would mean a commitment to remove
them within X number of versions, which I am not sure we will do. Now,
if phpdoc has a @discouraged token, I'd like to hear about it ;-)
Author: Tim Hunt <T.J.Hunt@open.ac.uk>
Signed-off-by: Martin Langhoff <martin@catalyst.net.nz>
(..., $field1, $value1, $field2, $value2, $field3, $value3, ...)
part of argument lists to a common method, and improve the
comments relating to those arguments on calling methods.
Author: Tim Hunt <T.J.Hunt@open.ac.uk>
Signed-off-by: Martin Langhoff <martin@catalyst.net.nz>
the new get_fieldset_sql() gets around the nastiness in get_recordset()
that treats the first column as the unique key of the recordset. You can
now request a column from a table, or a set of values as a set of 1 field
records.
Users can now be assigned to multiple groups. Thanks Yu!
Break out the Bob Marley!!
Otherwise groups work more or less like they did before.
This has been pretty well tested by Yu and myself, but since Yu started
uncovering lots of existing groups bugs it's possible there may be still
a few corner cases still lurking here and there.
Please help test this thoroughly for 1.6!!
skodak