https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20664 --- Comment #86 from David Cook <dcook@prosentient.com.au> --- (In reply to Marcel de Rooy from comment #84)
+ # This is so much faster than using Koha::Items->search that it makes sense even if it's ugly. + my $query = 'SELECT * FROM items WHERE biblionumber = ?';
Patch still applies. If I am reading thru the comments above, the main point of discussion is now: Do we want to return to raw sql in the above lines? It is rather obvious that this is faster than Koha::Object/DBIx. But we made a choice for DBIx and are still wrestling to implement it in the codebase. What would be the decisive reason for making the exception here, and would it be a precedent for doing similar things elsewhere? Also note that although the test plan refers to verifying that things are faster, I do not see any benchmark figures on the report.
Moving to discussion and sending mail to QA.
I'd say the decisive reason would be that the low-performance of DBIx::Class adds up when doing batch operations. While low-performance and high convenience might be tolerable for many single requests, if you're dealing with high volumes of data, it's a nightmare. Even fractions of a second per record can add up to unacceptably slow amounts of time. I've used raw SQL at https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10662#c221 for the same reason. I wish I had included benchmarks on that bug, but with the raw SQL and re-using the statement handle, I was able to process much higher volumes. I think it was like 100 records per second instead of 4 records per second. -- You are receiving this mail because: You are watching all bug changes.