https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18003
Josef Moravec <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #2 from Josef Moravec <[email protected]> --- (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. _______________________________________________ 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/
