https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21337
Marcel de Rooy <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|BLOCKED |Signed Off --- Comment #27 from Marcel de Rooy <[email protected]> --- (In reply to Jonathan Druart from comment #22) > I was not precise enough. > I use "something went wrong" for both cases: the row cannot be deleted > because of an error (FK for instance), or the row does not exist. > > With: > $p1 and p1bis can be deleted > $p2 cannot be deleted and DBI will explode > $p3 does not exist (and so $p3->delete will return 0) > > I would expect: > delete $p1 and $p1bis => ok, both are deleted > delete $p2 and ($p1 or $p3) => none are deleted, exception is raised > delete $p1 and $p3 => ok, $p1 is deleted Thanks. I understand what you mean now. I think that the last patch addresses your concerns now sufficiently. But note that the above is not precise enough :) If a FK error occurs (famous error: patron still has issues), Koha::Object::delete explodes and Koha::Patron::delete returns UNDEF ! So Koha::Patrons now needs to handle the inconsistency between Koha::Object->delete and Koha::Pattron->delete (..) Note that if a row does not exist, it may be hard to get a 0 return value. (Either it won't be in the set at all or we have a -1 for not in storage.) Hard to reproduce; see mocks in the test. Please have a look and pass QA if possible. -- 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/
