setting OU target weights can cause hold targeting to fail

[Galen Charlton]

If OU target weights higher than 1 are set in one or more OUs (via the circ.holds.org_unit_target_weight org unit setting), candidate items in those OUs can cause hold targeting to fail with the following errors in the Postgres log:

2013-06-24 20:11:40 PDT ERROR: duplicate key value violates unique constraint "copy_once_per_hold"
2013-06-24 20:11:40 PDT DETAIL: Key (hold, target_copy)=(197704, 24945627) already exists.

This appears to be caused by a change introduced in commit fc048034 (calculated proximity adjustments). Specifically, the proximity list generated in line 1542 of .../OpenILS/Application/Storage/Publisher/action.pm is then used to populate action.hold_copy_map for the hold being considered. However, when circ.holds.org_unit_target_weight for the copy circ OU is set to a value greater than one, multiple instances of that copy are inserted into the proximity list (as part of functionality to randomize, in a weighted fashion, which copies are chosen to fill the hold).

As a consequence, the hold targeter would then try to insert multiple rows into ahcm that having the same {hold, target_copy}, violating the copy_once_per_hold constraint and thereby causing the targeting for that hold to fail.

Evergreen 2.4.0

[Mike Rylander (mrylander)]

I offer http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/collab/miker/unique-copy-list to address that. From the commit at the top:

The development of Calculated Proximity Adjustment (CPA) for 2.4 added a "prox"
column to action.hold_copy_map (ahcm) to store on variant of copy proximity. That
value is calculated at the same time that certain other data structures are
set up, and is conceptually tied to them, so the resulting combined data
set is used to insert values into the ahcm. However, user configuration
can cause that data set to contain non-unique values, where the data structure
used previous to CPA was guaranteed to be unique. This lack of uniqueness
would then violate a constraint on the achm table. This commit restores the
required uniqueness for the purpose of creating the ahcm rows.

[Lebbeous Fogle-Weekley (lebbeous)]

I replicated the original problem with master, adding an org unit setting of name 'circ.holds.org_unit_target_weight' with a value of 2 to one of my org units, placing a title hold, and finding this in the Postgres logs:

> 2013-06-25 09:27:05 EDT ERROR: duplicate key value violates unique constraint "copy_once_per_hold"
> 2013-06-25 09:27:05 EDT DETAIL: Key (hold, target_copy)=(6, 29) already exists.
> 2013-06-25 09:27:05 EDT STATEMENT: INSERT INTO action.hold_copy_map (proximity, hold, id, target_copy) VALUES ('2', '6', '84', '29')

With Mike's commit applied, no more errors in the logs.

Signed off and pushed to master and rel_2_4.