[UXPROD-2735] Bulk APIs for Circulation Storage module Created: 07/Oct/20 Updated: 05/May/21 |
|
| Status: | Open |
| Project: | UX Product |
| Components: | None |
| Affects versions: | None |
| Fix versions: | None |
| Type: | New Feature | Priority: | TBD |
| Reporter: | Ian Walls | Assignee: | Ian Walls |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | bulk-api | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original estimate: | Not Specified | ||
| Issue links: |
|
||||||||||||||||||||||||||||
| Back End Estimate: | Large < 10 days | ||||||||||||||||||||||||||||
| Back End Estimator: | Marc Johnson | ||||||||||||||||||||||||||||
| Estimation Notes and Assumptions: | CB: Talked to Marc about this on a call and he thinks each one of these is probably about a sprint of work. Added the estimate. | ||||||||||||||||||||||||||||
| Development Team: | None | ||||||||||||||||||||||||||||
| PO Rank: | 90 | ||||||||||||||||||||||||||||
| PO Ranking Note: | Particularly important if historical circ is loaded; increases order of magnitude of expected records | ||||||||||||||||||||||||||||
| Rank: Chalmers (Impl Aut 2019): | R2 | ||||||||||||||||||||||||||||
| Rank: Chicago (MVP Sum 2020): | R2 | ||||||||||||||||||||||||||||
| Rank: Cornell (Full Sum 2021): | R1 | ||||||||||||||||||||||||||||
| Rank: Duke (Full Sum 2021): | R2 | ||||||||||||||||||||||||||||
| Rank: 5Colleges (Full Jul 2021): | R2 | ||||||||||||||||||||||||||||
| Rank: GBV (MVP Sum 2020): | R3 | ||||||||||||||||||||||||||||
| Rank: U of AL (MVP Oct 2020): | R3 | ||||||||||||||||||||||||||||
| Description |
|
Current situation or problem: In order to facilitate migrations in a timely and efficient manner, the Circulation Storage module needs to have batch APIs. POSTing, PUTting and DELETEing records one HTTP request and database commit at a time is unusably slow for large data sets. In scope:
Out of scope: Batch APIs for circulation rules, cancellation rules, fixed due date schedules, staff slips and other circulation settings are not required. The anticipated order of magnitude for these record sets is not sufficient to require batch handling. The individual record APIs are sufficient. Use case(s):
Comments: Loans are a much higher priority than Requests; Libraries can mitigate the number of pending quests at migration time, but the number of outstanding loans is not as a controllable. In order for these APIs to be effective, they need to bypass the business logic and go directly to the storage module. This means that bulk creation of loans will NOT update item status in Inventory, nor queue notifications to be sent to the user. The user of these APIs is responsible for maintaining data integrity; documentation needs to reflect this. |