Summary: | [WARN] DBIx::Class::ResultSetColumn::new(): Attempting to retrieve non-unique column 'biblionumber' on a resultset containing one-to-many joins will return duplicate results | ||
---|---|---|---|
Product: | Koha | Reporter: | Marcel de Rooy <m.de.rooy> |
Component: | Architecture, internals, and plumbing | Assignee: | Nick Clemens (kidclamp) <nick> |
Status: | RESOLVED FIXED | QA Contact: | Marcel de Rooy <m.de.rooy> |
Severity: | normal | ||
Priority: | P5 - low | CC: | david, emmi.takkinen, fridolin.somers, glasklas, jonathan.druart, lucas, magnus, nick, wainuiwitikapark |
Version: | Main | Keywords: | no-sandbox |
Hardware: | All | ||
OS: | All | ||
See Also: | https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36317 | ||
GIT URL: | Change sponsored?: | --- | |
Patch complexity: | Small patch | Documentation contact: | |
Documentation submission: | Text to go in the release notes: | ||
Version(s) released in: |
24.05.00,23.11.06,23.05.12
|
Circulation function: | |
Bug Depends on: | 33497 | ||
Bug Blocks: | |||
Attachments: |
Bug 34360: Get distinct biblionumber
Bug 34360: Get distinct biblionumber Bug 34360: Get distinct biblionumber |
Description
Marcel de Rooy
2023-07-24 14:41:38 UTC
NO This seems to be untrue. Happily. The accessor goes via _result. So could it be one of the 'genuine' calls of $self->get_column ? This is coming from commit 2cf00f1a49a7b9f8d5ca105e2dd1add5d5d95198 Bug 33497: Use 'host_items' param to fetch all items at once -my @items = $biblio->items->search_ordered( $params )->as_list; +my $items = $biblio->items({ host_items => 1 })->search_ordered( $params, { prefetch => ['issue','branchtransfers'] } ); And the get_column call from Koha::Items->search_ordered 453 my @biblionumbers = uniq $self->get_column('biblionumber'); I am failing at providing a correct fix. The warning looks bad, we should not ignore it. Created attachment 160842 [details] [review] Bug 34360: Get distinct biblionumber This fixes the problem noted in the bug: [WARN] DBIx::Class::ResultSetColumn::new(): Attempting to retrieve non-unique column 'biblionumber' on a resultset containing one-to-many joins will return duplicate results. at /usr/share/koha/Koha/Objects.pm line 421 We are taking a list of items, assuming the scenario is that these are from a single biblio and possibly some host_items, then searching and ordering conditionally on whether the biblio is a serial. Current code gets the first biblio from the list - this patch adds a 'DISTINCT' to the results ebfore fetching the column To test: 1 - Find a biblio in the staff interface 2 - Transfer one of the items a few times 3 - Recreate the issue on the command line: export DBIC_TRACE=1 perl -e 'use Koha::Items; my $items = Koha::Items->search({biblionumber=>9})->search_ordered(undef,{ prefetch => ['issue','current_branchtransfers'] }); $items->next' 4 - Note warning: DBIx::Class::ResultSetColumn::new(): Attempting to retrieve non-unique column 'biblionumber' on a resultset containing one-to-many joins will return duplicate results. at /kohadevbox/koha/Koha/Objects.pm line 426 5 - Apply patch 6 - Repeat 3 7 - Error is gone I added a patch, however, I noted a new error: DBIx::Class::ResultSet::_construct_results(): Unable to properly collapse has_many results in iterator mode due to order criteria - performed an eager cursor slurp underneath. Consider using ->all() instead at /kohadevbox/koha/Koha/Objects.pm line 317 Maybe that's a new bug? Surely related to the branchtransfers fetch, see bug 35100 I wonder on this one though, do we need to automagically decide how to sort? In the contexts where we use this we are looking at a specific biblio - could we put the onus on the caller to pass in the biblio serial column? Every call is using: $biblio->items->search_ordered() so we have the biblio. There is one exception in opac-detail.pl, however, it could be rewritten to use the 'host_items' option Suggesting: $biblio->items({search criteria})->search_ordered({ serial => $biblio->serial, other params},{}); Just a note: I am actually removing the branchtransfers join on bug 33568... Maybe it should re-introduce it (there is a FIXME there). (In reply to Nick Clemens from comment #6) > I added a patch, however, I noted a new error: > DBIx::Class::ResultSet::_construct_results(): Unable to properly collapse > has_many results in iterator mode due to order criteria - performed an eager > cursor slurp underneath. Consider using ->all() instead at > /kohadevbox/koha/Koha/Objects.pm line 317 Should this be fixed before the current patch is signed off? (In reply to Nick Clemens from comment #6) > I added a patch, however, I noted a new error: > DBIx::Class::ResultSet::_construct_results(): Unable to properly collapse > has_many results in iterator mode due to order criteria - performed an eager > cursor slurp underneath. Consider using ->all() instead at > /kohadevbox/koha/Koha/Objects.pm line 317 Have seen that one already in logs. But was hard to see where it came from exactly. Created attachment 166456 [details] [review] Bug 34360: Get distinct biblionumber This fixes the problem noted in the bug: [WARN] DBIx::Class::ResultSetColumn::new(): Attempting to retrieve non-unique column 'biblionumber' on a resultset containing one-to-many joins will return duplicate results. at /usr/share/koha/Koha/Objects.pm line 421 We are taking a list of items, assuming the scenario is that these are from a single biblio and possibly some host_items, then searching and ordering conditionally on whether the biblio is a serial. Current code gets the first biblio from the list - this patch adds a 'DISTINCT' to the results ebfore fetching the column To test: 1 - Find a biblio in the staff interface 2 - Transfer one of the items a few times 3 - Recreate the issue on the command line: export DBIC_TRACE=1 perl -e 'use Koha::Items; my $items = Koha::Items->search({biblionumber=>9})->search_ordered(undef,{ prefetch => ['issue','current_branchtransfers'] }); $items->next' 4 - Note warning: DBIx::Class::ResultSetColumn::new(): Attempting to retrieve non-unique column 'biblionumber' on a resultset containing one-to-many joins will return duplicate results. at /kohadevbox/koha/Koha/Objects.pm line 426 5 - Apply patch 6 - Repeat 3 7 - Error is gone Signed-off-by: baptiste <baptiste.bayche@inlibro.com> (In reply to Nick Clemens (kidclamp) from comment #6) > I added a patch, however, I noted a new error: > DBIx::Class::ResultSet::_construct_results(): Unable to properly collapse > has_many results in iterator mode due to order criteria - performed an eager > cursor slurp underneath. Consider using ->all() instead at > /kohadevbox/koha/Koha/Objects.pm line 317 I have been seeing this one regularly already on 22.11. (Perhaps on 21.11 already?) Hard to find out where it is coming from. Created attachment 166499 [details] [review] Bug 34360: Get distinct biblionumber This fixes the problem noted in the bug: [WARN] DBIx::Class::ResultSetColumn::new(): Attempting to retrieve non-unique column 'biblionumber' on a resultset containing one-to-many joins will return duplicate results. at /usr/share/koha/Koha/Objects.pm line 421 We are taking a list of items, assuming the scenario is that these are from a single biblio and possibly some host_items, then searching and ordering conditionally on whether the biblio is a serial. Current code gets the first biblio from the list - this patch adds a 'DISTINCT' to the results ebfore fetching the column To test: 1 - Find a biblio in the staff interface 2 - Transfer one of the items a few times 3 - Recreate the issue on the command line: export DBIC_TRACE=1 perl -e 'use Koha::Items; my $items = Koha::Items->search({biblionumber=>9})->search_ordered(undef,{ prefetch => ['issue','current_branchtransfers'] }); $items->next' 4 - Note warning: DBIx::Class::ResultSetColumn::new(): Attempting to retrieve non-unique column 'biblionumber' on a resultset containing one-to-many joins will return duplicate results. at /kohadevbox/koha/Koha/Objects.pm line 426 5 - Apply patch 6 - Repeat 3 7 - Error is gone Signed-off-by: baptiste <baptiste.bayche@inlibro.com> Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> Pushed for 24.05! Well done everyone, thank you! Pushed to 23.11.x for 23.11.06 Backported to 23.05.x for upcoming 23.05.12 Not backporting to 22.11 unless requested No updates to the manual required. |