https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18003 Josef Moravec <josef.moravec@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |josef.moravec@gmail.com --- Comment #2 from Josef Moravec <josef.moravec@gmail.com> --- (In reply to Jonathan Druart from comment #0)
Solution 1: Do not care about this problematic use case and prevent to delete the last patron.
I do not like this - it escalates the internal technical problem to end user...
Solution 2: Add a AI primary key (id) to deletedborrowers => The 2 tables borrowers and deletedborrowers will differ, bugs will be expected
It could be possible I think, but probably not easy to make it
Solution 3: Deal with that at code level: when a patron is created, guess the borrowernumber it will get and check if it does not already exist in the deletedborrowers table. If so, force it before inserting it
A bit complicated, but probably the best one
Solution 4: Do not enforce this constraint at DB level but set the primary key to DBIC schema: Koha::Schema::Result::Deletedborrower: __PACKAGE__->set_primary_key("borrowernumber"); Problem: Koha::Database->new->schema->resultset('Deletedborrower')->find(42); will raise a warning "DBIx::Class::Storage::DBI::select_single(): Query returned more than one row. SQL that returns multiple rows is DEPRECATED for ->find and ->single" if 42 is duplicated, and the first matching row will be picked
I do not like this too
Another solution?
So I am for 2 or 3, 2 was what came first to my mind, but the 3 is better I think... -- You are receiving this mail because: You are watching all bug changes.