[Koha-bugs] [Bug 21337] Add Koha::Patrons->delete (trivial wrapper)

bugzilla-daemon at bugs.koha-community.org bugzilla-daemon at bugs.koha-community.org
Thu Oct 25 13:12:24 CEST 2018


https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21337

--- Comment #21 from Marcel de Rooy <m.de.rooy at rijksmuseum.nl> ---
(In reply to Jonathan Druart from comment #17)
> IMO the following line is wrong:
>   $patron->delete == 1 || Koha::Exceptions::Patron::Delete->throw;
> 
> We must follow dbic behaviours and so we must not throw an exception if
> something went wrong (what DBIC does)

See also comment 7 (what you wrote before):

> I do not think the implementation is correct. DBIC would execute only 1
> query on Set->delete, which means no entries will be removed if at least one
> cannot be removed.
> I would say we should do the same, i.e. execute in a transaction and
> rollback if something went wrong.

The third patch implemented your suggestion from comment7, but it sounds like
your comment17 wants to revert that again? Probably misunderstanding what you
mean, so please clarify.

In the meantime noting that the txn_do in Patrons::delete has the disadvantage
(like in a few other places too) that the following statements behave the same
with AUTOCOMMIT==1 but behave differently in a test (nested transaction):

eval { Koha::Patrons->search({ borrowernumber => [ $id1, $id2 ] })->delete };
eval { $schema->resultset('Borrower')->search({ borrowernumber => [ $id1, $id2
] })->delete };

In the nested transaction (so in the test script) the txn_do does not rollback
the delete of $id1 when $id2 failed. But it does when there is no nested
transaction.

-- 
You are receiving this mail because:
You are watching all bug changes.


More information about the Koha-bugs mailing list