http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15107 --- Comment #1 from cnorthcott.work@gmail.com --- Created attachment 44447 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=44447&action=edit Bug 15107: Batch Patron Deletion (Trash) Performance Improvement Batch Patron Modification has a fairly long run/load time. I have attempted to improve the runtime of the Batch Patron Modification tool by switching out more expensive resultset calls for faster more direct SQL queries. Test Plan: 1) Prepare NTYprof (http://wiki.koha-community.org/wiki/Profiling_with_Devel::NYTProf) or procure a stopwatch (stopwatch will be simpler but less accurate). 2) Ensure you have a decent number of patrons in your Koha system (>500) if you are lacking patrons to modify in your database you can import 1000 using the PatronDataCSV.csv attachement and the Import Patrons tool before moving to step 3. 4) Navigate to Home > Tools > Batch Patrons Deletion in the Koha Intranet 5) Check the box beside the "Verify you want to delete patrons" box 6) Under "who have not borrowed since" enter todays date 7) You should get a message saying: "1000 patrons will be deleted 0 checkout history will be anonymized" If not please go back to step 2 and import patrons using the PatronDataCSV.csv 8) Select the radio button option beside "Move these patrons to the trash" 9) If you are using a stopwatch, prepare your stopwatch so that you will start counting seconds from the point you click the button in the next step. 10) Click the "Finsh" button (simultaneously start your stopwatch if using one) 11) When the page appears showing completion of the change, stop your stopwatch and check the time or navigate to the folder you have set NYTProf to output. 12) Record the runtime. This is the pre-optimisation time. 13) Apply this patch. 14) Repeat steps 2-12 of this testplan with the patch applied. This will yield the post-optimisation time. 15) Compare the pre-optimisation time and post optimisation time. The second post-optimisation time should be faster. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15107 Martin Renvoize <martin.renvoize@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |martin.renvoize@ptfs-europe | |.com --- Comment #5 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- Hi Catherine, What sort of appetite do you have for expanding the scope of this as hinted above? I feel koha is in a somewhat transitional stage at the moment regarding performance/coding standards.. I certainly don't wan't to put you off this important work but would like to see some alternatives that actually attempt to fix up the api's rather than make 'fixes' on top of old design decisions. For instance, the 'Move' routine not being a Move at all, but rather a Copy.. this is leading to bugs elsewhere. Also, the routine not being clear as to whether it requires a borrowernumber or a member hashref is likely to lead to bugs. I also think there could be an improvement to allow for passing lists of borrowernumber as a posed to single borrowers which could lead to performance gains too. This is all skirting the issue of data integrity and the lack of good db constraints meaning that objects could well become orphans after running this routine :( Any thoughts? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15107 Kyle M Hall <kyle@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kyle@bywatersolutions.com --- Comment #7 from Kyle M Hall <kyle@bywatersolutions.com> --- I agree with Martin. I would prefer we don't move backwards. If we can find a way to improve the speed while retaining DBIC that would be best. Maybe we could cache the result set as a package variable ( use vars )? Or maybe re-engineer the subroutine to accept a list of patrons to copy? I also think Martin is correct in that it would be great if you would be willing to fix the semantic issues with the code. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.