Bug 29441 - We should make our method returns consistent in Koha::Biblio
Summary: We should make our method returns consistent in Koha::Biblio
Status: NEW
Alias: None
Product: Koha
Classification: Unclassified
Component: Architecture, internals, and plumbing (show other bugs)
Version: master
Hardware: All All
: P5 - low enhancement (vote)
Assignee: Bugs List
QA Contact: Testopia
Depends on:
Reported: 2021-11-09 13:44 UTC by Martin Renvoize
Modified: 2022-05-25 11:20 UTC (History)
5 users (show)

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


Note You need to log in before you can comment on or make changes to this bug.
Description Martin Renvoize 2021-11-09 13:44:09 UTC
We now have a few of 'get_marc_*' accessors in Koha::Biblio, but their returns are really inconsistent.

I feel like we aught to try and make them as consistent as possible so future developers can use them without having to dig through the code to see what they return.

In `get_marc_notes` we return an array of note strings from the marc record.. these may be selective subfield concatenations and could be in various orders.

In `get_marc_host` we return either a Koha::Biblio object or the Biblio object + the subfield g, as a string, from the current records marc21 773 field we used to find the host.

In `get_marc_components` we return an array of MARCXML strings.

I think we could do better here.. certainly with the `_components` and `_host` routines either consistently returning Koha::Biblio/Koha::Biblios or MARCXML string/strings for example.  As for `get_marc_notes`, this is a little different.. we could possibly return an array of MARC::Field objects for later processing, or perhaps we aught to have a second naming scheme for returning strings from MARC/Metadata vs retuning a marc/metadata object/string itself?
Comment 1 Martin Renvoize 2021-11-09 13:52:04 UTC
On first look.. I feel like 'MARCXML' strings or 'MARC::Record' objects would be the right thing to return from the `get_marc_` accessors.. and then the consumer uses this response to do the next thing.. be that parse the string with XSLT for display, or get the Koha::Biblio using the data within.. I suggest this as it's what's returned from the search engine used for the two existing calls and thus reduces reduces further calls internally that may not be required.

As for get_marc_notes.. perhaps we would be better going back to 'get_notes' or 'get_notes_from_marc' to set a distinction between 'something that returns a MARC thing' and 'something that returns string/s from inside the MARC'