https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43692 Bug ID: 43692 Summary: Update Databases Selectively (Not Entire Row) Initiative type: --- Sponsorship --- status: Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs@lists.koha-community.org Reporter: trevor.diamond@mainlib.org QA Contact: testopia@bugs.koha-community.org Target Milestone: --- When items and holds are updated, the update command contains the entire row of information. Different processing/internet speeds means that and item update can go into effect seconds after it is checked out. The result is that the item is updated to the status it was when the modifying staff person clicked "save" and not the status after checkout. So an item will be checked out but have a NULL onloan value. The lifetime issues count and Datelastseen will revert to their old values. Similarly, when updating holds priority, the entire set of holds is sent for the entire bib record. Instead of just updating the priority, the entire hold row is sent. A patron might update holds on a bib. While the updates are processing an item is checked in and a hold put on the hold shelf. After the updates finish processing, the old data is restored for that hold. So there is an item on the shelf with a hold slip, but Koha thinks the hold is still looking for an item. There is no specific hold status for an item, so the item appears available. The item will appear on the picklist the next time the staff look (often for the same patron that it is already on the hold shelf for). If it's an especially popular title, you might have patrons entering the library hoping to find the copy on the shelf (a copy that is on the holds shelf, not up for general patrons to find). Both of these problems occur due to inefficient methods of updating table data. Instead, only the relevant information should be sent/updated in the database (example: only update priority and don't overrwrite at all if the priority is now 0). As Koha grows more sophisticated and tables get larger, this type of data updating will become more and more valuable in letting larger library / library cooperatives function without errors that mystify front line staff (who often aren't aware of activity happening in other libraries or on the opposite side of the building). -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.