Speed up deleting of global user achievements. #2710
Conversation
|
You can test this using the class list provided in #2709 and in combination with testing that pull request. Delete the users from imported and for which the achievements are assigned for testing that pull request. |
If you have payed attention (or tested openwebwork#2709 and openwebwork#2710), then you know that this takes a long time if there are a large number of users. Way to long to be at all reasonable. This uses techniques like those used for assigning multiple sets to users, i.e., the `WeBWorK::DB::Schema::NewSQL::Std::insert_records` and `WeBWorK::DB::Schema::NewSQL::Std::put_records` methods, to speed up assignment of achievements to users. This brings the assignment time for 5000 users down from more than 8 minutes, to less than 30 seconds.
If you have payed attention (or tested openwebwork#2709 and openwebwork#2710), then you know that this takes a long time if there are a large number of users. Way to long to be at all reasonable. This uses techniques like those used for assigning multiple sets to users, i.e., the `WeBWorK::DB::Schema::NewSQL::Std::insert_records` and `WeBWorK::DB::Schema::NewSQL::Std::update_records` methods, to speed up assignment of achievements to users. This brings the assignment time for 5000 users down from more than 8 minutes, to less than 30 seconds.
If you have payed attention (or tested openwebwork#2709 and openwebwork#2710), then you know that this takes a long time if there are a large number of users. Way to long to be at all reasonable. This uses techniques like those used for assigning multiple sets to users, i.e., the `WeBWorK::DB::Schema::NewSQL::Std::insert_records` and `WeBWorK::DB::Schema::NewSQL::Std::update_records` methods, to speed up assignment of achievements to users. This brings the assignment time for 5000 users down from more than 8 minutes, to less than 30 seconds.
If you have payed attention (or tested openwebwork#2709 and openwebwork#2710), then you know that this takes a long time if there are a large number of users. Way to long to be at all reasonable. This uses techniques like those used for assigning multiple sets to users, i.e., the `WeBWorK::DB::Schema::NewSQL::Std::insert_records` and `WeBWorK::DB::Schema::NewSQL::Std::update_records` methods, to speed up assignment of achievements to users. This brings the assignment time for 5000 users down from more than 8 minutes, to less than 30 seconds.
If you have payed attention (or tested openwebwork#2709 and openwebwork#2710), then you know that this takes a long time if there are a large number of users. Way to long to be at all reasonable. This uses techniques like those used for assigning multiple sets to users, i.e., the `WeBWorK::DB::Schema::NewSQL::Std::insert_records` and `WeBWorK::DB::Schema::NewSQL::Std::update_records` methods, to speed up assignment of achievements to users. This brings the assignment time for 5000 users down from more than 8 minutes, to less than 30 seconds.
|
The new line 1471 assumes |
|
All of the hash keys of Basically this method is entirely inconsistent with every other method in this file. If this were consistent, then every method in this file should perform this same check to see that the hash key for the corresponding schema is defined before doing anything. Since we do not support alternate database layouts anymore, and furthermore, since there won't even be the option to have an alternate database layout soon (once #2702 is merged), this check is just not needed. |
If you have payed attention (or tested openwebwork#2709 and openwebwork#2710), then you know that this takes a long time if there are a large number of users. Way to long to be at all reasonable. This uses techniques like those used for assigning multiple sets to users, i.e., the `WeBWorK::DB::Schema::NewSQL::Std::insert_records` and `WeBWorK::DB::Schema::NewSQL::Std::update_records` methods, to speed up assignment of achievements to users. This brings the assignment time for 5000 users down from more than 8 minutes, to less than 30 seconds.
drgrice1
force-pushed
the
delete-global-user-achievement-speed-tweak
branch
from
c6c6ba3 to
2943b31
Compare
If you have payed attention (or tested openwebwork#2709 and openwebwork#2710), then you know that this takes a long time if there are a large number of users. Way to long to be at all reasonable. This uses techniques like those used for assigning multiple sets to users, i.e., the `WeBWorK::DB::Schema::NewSQL::Std::insert_records` and `WeBWorK::DB::Schema::NewSQL::Std::update_records` methods, to speed up assignment of achievements to users. This brings the assignment time for 5000 users down from more than 8 minutes, to less than 30 seconds.
drgrice1
force-pushed
the
delete-global-user-achievement-speed-tweak
branch
from
2943b31 to
9d37488
Compare
Instead of listing user achievements and then deleting them one by one in a loop, just delete them with one query using a `where` statement.
drgrice1
force-pushed
the
delete-global-user-achievement-speed-tweak
branch
from
9d37488 to
ebd2e99
Compare
Instead of listing user achievements and then deleting them one by one in a loop, just delete them with one query using a
wherestatement.This improved the deletion of 5000 users all of which had the default set of achievements assigned to them from taking a minute and a half to less than 20 seconds.