Bug 23187

Summary: Koha::Objects supports find_or_create without passing through the Koha::Object store method
Product: Koha Reporter: Martin Renvoize <martin.renvoize>
Component: Architecture, internals, and plumbingAssignee: Bugs List <koha-bugs>
Status: NEW --- QA Contact: Testopia <testopia>
Severity: major    
Priority: P1 - high CC: dcook, jonathan.druart, koha-bugs, kyle, m.de.rooy, martin.renvoize, testopia, tomascohen
Version: Main   
Hardware: All   
OS: All   
See Also: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23185
Change sponsored?: --- Patch complexity: ---
Documentation contact: Documentation submission:
Text to go in the release notes:
Version(s) released in:
Bug Depends on: 21761    
Bug Blocks:    

Description Martin Renvoize 2019-06-21 16:00:39 UTC
+++ This bug was initially created as a clone of Bug #21761 +++

If we're adding triggers at the code level all over the place by overloading the store method we need to never ever let dbic handle it.. by allowing directly passing data to dbic's find_or_create method in Koha::Objects we are exposing ourselves to places in the codebase skipping the store triggers.
Comment 1 Jonathan Druart 2019-12-11 08:55:54 UTC
Should we remove Koha::Objects->find_or_create?
There are very few occurrences so far.
Comment 2 Martin Renvoize 2019-12-11 09:03:58 UTC
(In reply to Jonathan Druart from comment #1)
> Should we remove Koha::Objects->find_or_create?
> There are very few occurrences so far.

I reckon that's the most pragmatic approach.. it won't be too onerous to split the calls in two.. that's what happens behind the scenes in dbic land anyway.

However.. do we use any of the create_related or multi-create functionality of dbic?  That uses the internal find_or_create behind te scenes inside dbic.
Comment 3 Katrin Fischer 2023-10-08 11:14:46 UTC
> Should we remove Koha::Objects->find_or_create?
> There are very few occurrences so far.

There are still occurrences of find_or_create in the codebase, so I believe this hasn't been resolved yet.(In reply to Jonathan Druart from comment #1)