https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23070
--- Comment #3 from Martin Renvoize <[email protected]> --- (In reply to Jonathan Druart from comment #2) > I am missing a DBIx::Class trick to make this better. If we were not getting rid of being able to call dbic's 'update' routine there might be.. though even then I think you'd need to pass some raw sql via a scalar ref.. something along the lines `Koha::Holds->search({ biblionumber => $hold->biblionumber, priority => { '>' => 0 } })->update({ priority => \'priority + 1' });` However, as we're keen to ensure we always go via our 'store' codepath to catch triggers then that is the equivalent to having to call ->update_all in DBIx::Class::ResultSet world.. which as that triggers a loop internally and a db hit per row rather than a db hit for the set then what you've got here seems the best we can do. We could possibly get clever when we work on a solution for our version of update and check whether there are triggers in the local store routing and either call dbics underlying update directly or manipulate it into a loop which calls our store routines much like dbic does for update_all. -- You are receiving this mail because: You are watching all bug changes. _______________________________________________ Koha-bugs mailing list [email protected] http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
