It turns out my question about queue position is moot... There is a significant amount of supporting code for holds that assumes the holds data exists in a certain format, namely the format returned from "open-ils.circ.hold.details.retrieve" and friends. Because of this, we have to fetch the extra details data for every hold regardless.
The grid now renders itself using the sort-able "ahopl" class with a canned grid query. Once all holds are retrieved, an additional batch/streaming call is made to fetch the extra details for all of the holds on display. This data is cached, so re-sorts, etc. will not cause another details fetch.
The 2nd commit in the branch resolves a cstore exhaustion problem with
open-ils.circ.hold.details.batch.retrieve.authoritative.
New branch with 2 commits pushed:
http:// git.evergreen- ils.org/ ?p=working/ Evergreen. git;a=shortlog; h=refs/ heads/user/ berick/ lp1653001- webstaff- idl-pull- list
It turns out my question about queue position is moot... There is a significant amount of supporting code for holds that assumes the holds data exists in a certain format, namely the format returned from "open-ils. circ.hold. details. retrieve" and friends. Because of this, we have to fetch the extra details data for every hold regardless.
The grid now renders itself using the sort-able "ahopl" class with a canned grid query. Once all holds are retrieved, an additional batch/streaming call is made to fetch the extra details for all of the holds on display. This data is cached, so re-sorts, etc. will not cause another details fetch.
The 2nd commit in the branch resolves a cstore exhaustion problem with circ.hold. details. batch.retrieve. authoritative.
open-ils.