-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update ODL hold calculation logic (PP-1728) #2117
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #2117 +/- ##
=======================================
Coverage 90.72% 90.72%
=======================================
Files 351 351
Lines 40878 40886 +8
Branches 8853 8871 +18
=======================================
+ Hits 37085 37093 +8
Misses 2486 2486
Partials 1307 1307 ☔ View full report in Codecov by Sentry. |
a4928ee
to
820376e
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Whoa: big PR. Looks good to the extent that I fully grocked it. Way to move another task out of the scripts and into celery.
Description
Completely re-work how we are calculating the hold queue for OPDS2 + ODL items.
All the work to calculate the holds is moved out to live in a Celery task. When a hold is invoked through the API the hold is always placed in the queue, and the queue is later recalculated by the celery task.
Motivation and Context
Previously the holds calculation was based on the number of loans that this CM had for an item. This is a problem is a loan gets lost, or if the collection is added to multiple CM. Now we use the number of licenses available, which should be safer and less error prone. However it may still be incorrect if the collection is on multiple CM, as these CM will be fighting for the same hold.
How Has This Been Tested?
Checklist