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: [email protected]
          Reporter: [email protected]
        QA Contact: [email protected]
  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.
_______________________________________________
Koha-bugs mailing list -- [email protected]
To unsubscribe send an email to [email protected]
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/

Reply via email to