[Koha-bugs] [Bug 18003] Should deletedborrowers.borrowernumber be a primary key?

[bugzilla-daemon at bugs.koha-community.org]

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

Josef Moravec <josef.moravec at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |josef.moravec at gmail.com

--- Comment #2 from Josef Moravec <josef.moravec at 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.