| 2010-08-27 15:16:16 |
Ben Shum |
description |
EG Version: 1.6.0.2
OpenSRF Version: 1.2.2
PostgreSQL Version: 8.3
Linux distribution: Debian
When we went live with our first development partner libraries back in March 2010, we noticed that there was a major problem with the way that holds were being matched against the rules set in the config.hold_matrix_matchpoint table. Some hold rules that were supposed to protect certain items from being placed on hold by certain groups were not doing their job correctly. Instead the items in question were being matched to incorrect rules in the matchpoint table that were allowing holds to go through.
Working with Galen Charlton from ESI, we tracked the potential source of the problem to something in how the holds matching logic applied with regards to the requestor.grp field in the hold matrix. As explained to us, the problem was often that once a hold request matched to a particular requesting user group's hold rule, it would fail to recognize a more specific rule that should have matched better elsewhere in the table. Too much weight was being applied to the requestor.grp and that was messing up all our hold placements.
Currently, we have an adjusted hold matrix matching logic that skips matches to the requestor.grp as a temporary measure, but would like to find a better solution with the community.
Will try to supply additional information as best I can. |
EG Version: 1.6.0.2
OpenSRF Version: 1.2.2
PostgreSQL Version: 8.3
Linux distribution: Debian
When we went live with our first development partner libraries back in March 2010, we noticed that there was a major problem with the way that holds were being matched against the rules set in the config.hold_matrix_matchpoint table. Some hold rules that were supposed to protect certain items from being placed on hold by certain groups were not doing their job correctly. Instead the items in question were being matched to incorrect rules in the matchpoint table that were allowing holds to go through.
Working with Galen Charlton from ESI, we tracked the potential source of the problem to something in how the holds matching logic applied with regards to the requestor.grp field in the hold matrix. As explained to us, the problem was often that once a hold request matched to a particular requesting user group's hold rule, it would fail to recognize a more specific rule that should have matched better elsewhere in the table. Too much weight was being applied to the requestor.grp and that was messing up all our hold placements.
Currently, we have an adjusted hold matrix matching logic that skips matches to the requestor.grp as a temporary measure, but would like to find a better solution with the community. A big question we have is how the current holds logic is applied to finding matchpoints and what weights are assigned to particular fields.
Will try to supply additional information as best I can.
|
|
