https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23070 --- Comment #9 from Tomás Cohen Arazi <tomascohen@gmail.com> --- (In reply to Martin Renvoize from comment #3)
(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.
I'm leaning towards thinking we shouldn't use a catch-all ->store method, but an ->insert and an ->update methods... There's a reasoning behind how DBIC does things... We've gone too far with our use of ->update_or_insert and we end up having a big IF clause on the more interesting Koha::Object-derived classes, to detect if it is an update or an insert... And I also belive many business stuffs should be on the controllers instead. We are inserting too many things in the DAO (not exactly the pattern, I know) only to be backwards compatible. That said, this patches look correct the way our codebase is going forward. -- You are receiving this mail because: You are watching all bug changes.