Bug 10004 - Delay batch record count updates until the end of the z39.50 search
Summary: Delay batch record count updates until the end of the z39.50 search
Status: CLOSED FIXED
Alias: None
Product: Koha
Classification: Unclassified
Component: Z39.50 / SRU / OpenSearch Servers (show other bugs)
Version: Main
Hardware: All All
: P5 - low minor (vote)
Assignee: Kyle M Hall
QA Contact:
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-04-08 18:20 UTC by Kyle M Hall
Modified: 2014-05-26 21:04 UTC (History)
2 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments
Bug 10004 - Delay batch record count updates until the end of the z39.50 search (4.44 KB, patch)
2013-04-08 18:21 UTC, Kyle M Hall
Details | Diff | Splinter Review
Bug 10004 - Delay batch record count updates until the end of the z39.50 search (4.91 KB, patch)
2013-04-08 19:35 UTC, Kyle M Hall
Details | Diff | Splinter Review
Bug 10004 - Delay batch record count updates until the end of the z39.50 search (4.87 KB, patch)
2013-04-08 19:36 UTC, Kyle M Hall
Details | Diff | Splinter Review
Bug 10004 - Delay batch record count updates until the end of the z39.50 search (4.89 KB, patch)
2013-04-08 19:39 UTC, Kyle M Hall
Details | Diff | Splinter Review
Bug 10004 - Delay batch record count updates until the end of the z39.50 search [3.8.x] [3.10.x] (7.36 KB, patch)
2013-04-09 12:03 UTC, Kyle M Hall
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Kyle M Hall 2013-04-08 18:20:45 UTC
Right now when a z39.50 search is run, _update_batch_record_counts is run for each record. If multiple duplicate bibs are in the search, it will be run for each of them. For Koha installations with very large numbers of batches, this can cause significant slowdowns. It would be better to delay this update until the very end so we can update each batch only once.
Comment 1 Kyle M Hall 2013-04-08 18:21:21 UTC Comment hidden (obsolete)
Comment 2 Kyle M Hall 2013-04-08 19:35:35 UTC Comment hidden (obsolete)
Comment 3 Kyle M Hall 2013-04-08 19:36:29 UTC Comment hidden (obsolete)
Comment 4 Kyle M Hall 2013-04-08 19:39:14 UTC
Created attachment 17299 [details] [review]
Bug 10004 - Delay batch record count updates until the end of the z39.50 search

Right now when a z39.50 search is run, _update_batch_record_counts is
run for each record. If multiple duplicate bibs are in the search, it
will be run for each of them. For Koha installations with very large
numbers of batches, this can cause significant slowdowns. It would be
better to delay this update until the very end so we can update each
batch only once. In addition, we can fork this process, as it is not
neccessary to wait for it before displaying results.

Test Plan:
1) Apply patch
2) Perform a z39.50 search
Comment 5 Kyle M Hall 2013-04-09 12:03:24 UTC Comment hidden (obsolete)
Comment 6 Marcel de Rooy 2013-04-10 12:09:44 UTC
Hm. I am not sure if we really should start forking in a cgi script. (Not saying that your solution would not work :)

But going one step back: Can we not just get rid of these *silly* record counts for Z3950 searches? These counts may be of some interest for staged marc files and so on. But what are we doing with these numbers for Z3950 search? I cannot recall seeing this number anywhere in Koha.

So, why not stop calculating instead of doing it in a second process?
Comment 7 Kyle M Hall 2013-04-23 15:30:03 UTC
I believe these numbers are updated because the records found via the z39.50 search go into the import_records table. Each time a record is added to that batch, the count is recalculated and stored in the import_batches table. 



(In reply to comment #6)
> Hm. I am not sure if we really should start forking in a cgi script. (Not
> saying that your solution would not work :)
> 
> But going one step back: Can we not just get rid of these *silly* record
> counts for Z3950 searches? These counts may be of some interest for staged
> marc files and so on. But what are we doing with these numbers for Z3950
> search? I cannot recall seeing this number anywhere in Koha.
> 
> So, why not stop calculating instead of doing it in a second process?
Comment 8 Kyle M Hall 2013-04-23 15:31:01 UTC
I should also not a number of our cgi scripts fork children for ajax purposes, so this is not without precedent.
Comment 9 Marcel de Rooy 2013-04-24 11:18:38 UTC
(In reply to comment #7)
> I believe these numbers are updated because the records found via the z39.50
> search go into the import_records table. Each time a record is added to that
> batch, the count is recalculated and stored in the import_batches table. 

You describe what happens but why should we do something that we do not use later?
Comment 10 Marcel de Rooy 2013-07-31 07:13:57 UTC
Bug 10462 has resolved the issue of the unused batch record counts for Z3950 search.