http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=1774 ------- Comment #5 from drdrulm@yahoo.com 2008-01-30 10:35 ------- Hello, I thought Ryan implied we were up to date. The bug is still there. Also, we do have the problem, when a specific item is put on hold, then no one else can request that specific item. This seems like a list of priority queues. http://en.wikipedia.org/wiki/Priority_queue Where each specific item has it's own priority queue. I need to think about an algorithm for this. I mean, if someone requests a specific copy and it is there you give it to them, but if someone else wants the same copy, then they would be at position 2, then 3 and so on. Each item would have a queue. One would ask themselves, how does one do this? Other ILSs seem to only allow patrons to request specific copies, and each ITEM has a queue. Of course it doesn't matter if the copies are alike. When the copies are different then we really need a queue on each item. Really that is the way it would work anyway. So how do we do this given there is a single numbered list. The way to do this, would be allow multiple position 1's, 2's, 3's etc. which reserves already does. When a reserve goes on, have some logic: if (! item level reserve) { This is *not* item level hold so... take MAX of all reserves FOR EACH ITEMNUM!! for this BIB add 1 -> new rank // say WIRED has 12 issues, and the latest 3 issues have 5 reserves each, // if a person then wanted ANY wired, they would be RANK 1 since there are // 9 other issues with NO holds. The SQL+Perl may be a bit tricky } else { This *is* an item level hold (easier!) take MAX of all reserves FOR *ONLY* THIS ITEMNUM, and add 1 -> new rank // so if we made a HOLD on the most recent WIRED magazine, it has 5 reserves // so we would be rank 6 for this item } The return algorithm is as strange, but still must look at the itemnumber Return() { Look at item coming in, decrease all ranks for BIB by 1 for *only* item-level holds for that item. After this, then take the MAX again of all item level holds, it may decrease or it may not! If it decreased (by 1) then subtract 1 from all general holds. If it did not decrease leave general hold ranks the same. The number would not decrease when an item was returned with a queue that was shorter than another item level queue. } This may sound complex, but thinking about this kind of thing is all I ever have done. My intuition with algorithms is pretty sound. Here is a reference in case you think the above is "nuts" http://citeseer.ist.psu.edu/cache/papers/cs/30321/http:zSzzSzwww.cs.kent.edu... So that should be the nuts and bolts of how to deal with an item level reserve without actually using lists of priority queues. Just let some SQL/perl logic deal with it. As for the other bug, it seems that MAX is not being computed correctly. 8) ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.