Bug 28709 - Fetching biblio objects for custom covers is inefficient
Summary: Fetching biblio objects for custom covers is inefficient
Status: CLOSED WONTFIX
Alias: None
Product: Koha
Classification: Unclassified
Component: Searching (show other bugs)
Version: Main
Hardware: All All
: P5 - low normal
Assignee: Nick Clemens (kidclamp)
QA Contact: Testopia
URL:
Keywords:
Depends on: 22445
Blocks:
  Show dependency treegraph
 
Reported: 2021-07-13 18:26 UTC by Nick Clemens (kidclamp)
Modified: 2022-12-12 21:25 UTC (History)
4 users (show)

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


Attachments
Bug 28709: Refactor Koha::Biblio->custom_cover_image_url to allow passing parameters (9.51 KB, patch)
2021-07-13 18:31 UTC, Nick Clemens (kidclamp)
Details | Diff | Splinter Review
Bug 28709: Refactor Koha::Biblio->custom_cover_image_url to allow passing parameters (9.52 KB, patch)
2021-07-13 18:33 UTC, Nick Clemens (kidclamp)
Details | Diff | Splinter Review
Bug 28709: Refactor Koha::Biblio->custom_cover_image_url to allow passing parameters (9.57 KB, patch)
2021-07-14 12:26 UTC, Owen Leonard
Details | Diff | Splinter Review
Bug 28709: Refactor Koha::Biblio->custom_cover_image_url to allow passing parameters (10.43 KB, patch)
2021-07-20 11:43 UTC, Nick Clemens (kidclamp)
Details | Diff | Splinter Review
Bug 28709: Refactor Koha::Biblio->custom_cover_image_url to allow passing parameters (10.69 KB, patch)
2021-11-15 14:43 UTC, Jonathan Druart
Details | Diff | Splinter Review
Bug 28709: Refactor Koha::Biblio->custom_cover_image_url to allow passing parameters (10.70 KB, patch)
2021-11-16 12:10 UTC, Nick Clemens (kidclamp)
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Nick Clemens (kidclamp) 2021-07-13 18:26:17 UTC
Bug 22445 added the ability to define custom cover image urls using info from the bibliographic record

The method custom_cover_image_url is part of Koha::Biblio

To use the method the search results now fetch the Biblio object in individual calls in the results loop.

If the method is refactored to allow passing parameters we can use the values already calculated in the subroutine to generate the URL and pass only the URL to the templates
Comment 1 Nick Clemens (kidclamp) 2021-07-13 18:31:35 UTC Comment hidden (obsolete)
Comment 2 Nick Clemens (kidclamp) 2021-07-13 18:33:07 UTC Comment hidden (obsolete)
Comment 3 David Cook 2021-07-13 23:35:14 UTC
I like the motivation for the change, but I'm not sure about the style. What if we moved most of the logic out of "custom_cover_image_url" and into a separate class method. Then "custom_cover_image_url" could call that class method, and that class method could be used in the search results. I think that would make the code easier to read and maintain in the longer term.

But that's just my two cents. I know that it would be more work so might not be feasible. I've used the same style of checking if $self is a ref for times when I couldn't refactor more fully.

Always nice to see an efficiency improvement :)
Comment 4 Owen Leonard 2021-07-14 12:26:23 UTC Comment hidden (obsolete)
Comment 5 Jonathan Druart 2021-07-16 09:33:19 UTC
(In reply to David Cook from comment #3)
> I like the motivation for the change, but I'm not sure about the style. What
> if we moved most of the logic out of "custom_cover_image_url" and into a
> separate class method. Then "custom_cover_image_url" could call that class
> method, and that class method could be used in the search results. I think
> that would make the code easier to read and maintain in the longer term.

After I read the patches I was coming here to write that.


Missing occurrence:
koha-tmpl/opac-tmpl/bootstrap/en/modules/opac-opensearch.tt:    [% SET custom_cover_image_url = SEARCH_RESULT.biblio_object.custom_cover_image_url %]
Comment 6 Nick Clemens (kidclamp) 2021-07-20 11:43:49 UTC Comment hidden (obsolete)
Comment 7 Joonas Kylmälä 2021-11-13 14:43:45 UTC
Doesn't apply.
Comment 8 Jonathan Druart 2021-11-15 14:42:38 UTC
Are you sure we don't only need to pass/cache the MARC record?
Did you benchmark this patch?
Comment 9 Jonathan Druart 2021-11-15 14:43:08 UTC Comment hidden (obsolete)
Comment 10 Jonathan Druart 2021-11-15 14:43:42 UTC
Patch rebased (and tidied searchResults changes).
Comment 11 Nick Clemens (kidclamp) 2021-11-16 12:10:45 UTC
Created attachment 127688 [details] [review]
Bug 28709: Refactor Koha::Biblio->custom_cover_image_url to allow passing parameters

Currently the search result template receive a Koha::Biblio object and call the method.

The searchResults routine already has the isbn, issn, and normalized_isbn calculated.
Rather than fetching the object and passing to the template we can pass the parameters,
generate the url, and pass only the URL to the template

To test:
1 - Set the system preferences:
    CustomCoverImages : Display
    OPACCustomCoverImages: Display
    CustomCoverImagesURL: https://images-na.ssl-images-amazon.com/images/P/{normalized_isbn}.01.LZZZZZZZ.jpg
2 - Search on staff and opac for a term that returns titles with covers, e.g. 'shuffle'
3 - Confirm the covers show
4 - Apply patch
5 - Restart all
6 - Confirm covers still show
7 - prove -v t/db_dependent/Koha/Biblios.t
Comment 12 Nick Clemens (kidclamp) 2021-11-16 12:14:57 UTC
(In reply to Jonathan Druart from comment #8)
> Are you sure we don't only need to pass/cache the MARC record?
I suppose we could, but we have already called TransformMarcToKoha, why would we not pass the values we calculated?

> Did you benchmark this patch?
with numSearchResults at 50 - standard sample data, search for 'a'
Before patch ~2 second
After patch ~1.85 seconds
Comment 13 David Cook 2021-11-17 00:48:36 UTC
(In reply to Nick Clemens from comment #12)
> > Did you benchmark this patch?
> with numSearchResults at 50 - standard sample data, search for 'a'
> Before patch ~2 second
> After patch ~1.85 seconds

Is that averaged or based on 1 test each?
Comment 14 Nick Clemens (kidclamp) 2021-11-22 14:35:22 UTC
(In reply to David Cook from comment #13)
> (In reply to Nick Clemens from comment #12)
> > > Did you benchmark this patch?
> > with numSearchResults at 50 - standard sample data, search for 'a'
> > Before patch ~2 second
> > After patch ~1.85 seconds
> 
> Is that averaged or based on 1 test each?

I repeated the tests 10 times each, that was the average
Comment 15 Owen Leonard 2022-05-11 11:50:13 UTC
I'm getting an average improvement of .03 seconds, and I'm not sure what to say about that.
Comment 16 David Cook 2022-05-11 23:26:58 UTC
(In reply to Jonathan Druart from comment #8)
> Are you sure we don't only need to pass/cache the MARC record?
> Did you benchmark this patch?

Maybe it's worth looking again at this one with Devel::NYTProf to see where speed gains could be made...
Comment 17 Nick Clemens (kidclamp) 2022-05-12 12:52:22 UTC
The performance increase was lessened as the removal of the biblio fetch was lost during a rebase

Bug 3142 added a use of the biblio_object for checking holdability

Closing this one out