Jonathan Druart
a9a500e81d
Koha suffers of big bugs due to its history: When data are deleted, they
are moved to another tables.
For instance issues and old_issues: when a checkin is done, it is moved
to the old_issues table.
That leads to a main problem that is described on
https://wiki.koha-community.org/wiki/DBMS_auto_increment_fix
However we tried first to fix the problem (for issues/old_issues) at
code level on bug 18242.
The goal was to prevent data lost.
Data lost may happens in this case:
Check an item out (issue_id = 1)
Check an item in (issue_id = 1)
Restart MySQL (reset auto increment for issue_id to 1)
Check an item out (issue_id = 1)
Check an item in => BOOM, the issue_id is a PK in old_issues and the
move fails.
Before bug 18242 the data were lost, we inserted the value into
old_issues, which fails silently (because of RaiseError set to 0 in
Koha::Database), then delete the row from issues.
That has been fixed using a transaction.
This patch introduced a regression we tried to fix on bug 18651 comment
0, the patron was charged even if the checkin was rejected.
A good way to fix that would have been to LOCK the tables:
1- Start a transaction
2- LOCK the table to make sure nobody will read id and avoid race
conditions
3- Move the content from one table to the other, dealing with ids
4- UNLOCK the table
5- Commit the transaction
But there were problems using LOCK and DBIx::Class (See commit
|
||
---|---|---|
.. | ||
add_message.pl | ||
article-request-slip.pl | ||
article-requests.pl | ||
bookcount.pl | ||
branchoverdues.pl | ||
branchtransfers.pl | ||
circulation-home.pl | ||
circulation.pl | ||
del_message.pl | ||
hold-transfer-slip.pl | ||
offline-mf.pl | ||
offline.pl | ||
on-site_checkouts.pl | ||
overdue.pl | ||
pendingreserves.pl | ||
renew.pl | ||
request-article.pl | ||
reserveratios.pl | ||
returns.pl | ||
selectbranchprinter.pl | ||
transfer-slip.pl | ||
transferstoreceive.pl | ||
view_holdsqueue.pl | ||
waitingreserves.pl | ||
ypattrodue-attr-search-authvalue.pl | ||
ysearch.pl |