[Koha-bugs] [Bug 1774] New reserves do not go to end of list, but somewhere in middle

[bugzilla-daemon at pippin.metavore.com]

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=1774





------- Comment #5 from drdrulm at 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.eduzSzzCz7EparallelzSzpaperszSzulm_wmpp04.pdf/ulm04solving.pdf

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.