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: | Pushed to oldstable --- | 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 |
Version: | Main | Keywords: | no-sandbox |
Hardware: | All | ||
OS: | All | ||
See Also: | https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36317 | ||
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 |