Similarly to how the scheduled tasks work, we now automatically check
and make sure that all the models specified in the component's
db/analytics.php file exist during the installation or upgrade of the
component.
The original implementation did not work well for checking that the
given model does NOT exist. If no record was found in the
analytics_models table, the code execution continued and it reached the
moment when indicators were checked. If no indicators were provided, the
call ended up with error 'array_keys() expects parameter 1 to be array,
boolean given' (because indicators were set to false).
The functionality of the \core_analytics\manager::add_builtin_models()
method is to be replaced with automatic update of models provided by the
core moodle component. There is no need to call this method explicitly
any more. Instead, adding new models will be done by updating the
lib/db/analytics.php file and bumping the core version.
When the API had originally been designed, it was assumed that the
presence of the time splitting method implies no requirement for the
machine learning backend and that it is a sign of less performance
demanding models. So it seemed to be safe and useful to have such models
automatically enabled. That assumption did not prove to be valid. Most
of the time is spent calculating indicators that depend on log tables.
We realized it would be useful to be able to specify the default time
splitting method without the need to have such models auto-enabled.
Static predictions models (i.e. those using a target based on
assumptions, not facts) are always considered as trained. Clearing them
must not mark them as untrained. Doing so would make them being skipped
by the prediction scheduled task.
This method was used when the API was tied to students at risk model,
this method does not make sense any more as it is up to each target
to define what is a valid course.
- Basic unit test for minimum machine learning backends requirements
- Warning return messages now include not enough data
- Clear models when the predictions processor is changed
- Refined the name of a couple of constants / methods
This was supposed to be split into multiple commits to make it easier to understand
but I failed to do it properly. So this is the list of changes:
- New analytics_indicator_calc db table to store indicators calculations
- Reuse previous calculations during prediction/training; other models
previous calculations should also be reused as long as they belong to
the same sample (sampleid depends on sampleorigin), time range and indicator
- Allow bulk inserting of these calculations as this can hurt database performance
- Block the same analysable to be analysed for training and for prediction
- Use a new instance of the target and use it for is_valid_* functions
as using ::is_valid_sample can lead to problems if people
uses it to cache stuff
This was done for indicators, targets and time splitting methods so that we
can get the string identifier and component in order to display a help_icon.
The functions were also made abstract, removing the default implementation.
Indicators, targets and time splitting methods should define this function.
Now we only predict using the most recent range available, this means
that if someone upgrades to moodle 3.4 at three quarters of a course
we will only calculate the latest range, previous ranges were not
displayed anyway once more recent predictions were available.
This commit deletes all previous predictions :) this shouldn't be a
problem in master as we don't provide any guarantee, the alternative
(retrive sampleids from mdl_files) would have been slow and a waste of
time as well as require horrible code in an upgrade step (text fields
do not accept defaults nor we can use NOTNULL).
