40b2aca...
by
dbs <dbs@dcc99617-32d9-48b4-a31d-7c20da2025e4>
asset.uri needs a seed entry for queries of its ID values
To fix a problem with ingesting URIs, Ingest.pm was changed to reflect
the maximum asset.uri.id value rather than the asset.call_number.id
value. However, with no entries in asset.uri, the query returned a
NULL object which broke ingest entirely. Adding a seed entry avoids
this problem.
3d6209f...
by
gmc <gmc@dcc99617-32d9-48b4-a31d-7c20da2025e4>
do not use TRUNCATE when refreshing reporter.materialized_simple_record
Previous behavior would break Slony replication after doing a
bib load. Since a deletion is slower than a truncate, if you're
not using Slony replication, you may prefer to truncate rmsr
prior to calling reporter.enable_materialized_simple_record_trigger.
57f9180...
by
gmc <gmc@dcc99617-32d9-48b4-a31d-7c20da2025e4>
adjust user tests that get done when retargeting holds
Fixes bug where a user having the maximum number of
active hold requests allowed to them by policy would
prevent items from being targeted to fill their requests.
1b3256d...
by
dbs <dbs@dcc99617-32d9-48b4-a31d-7c20da2025e4>
Backport r18516: Ensure call numbers are returned to the holdings editor in ascending sorted order
James Fournie in https://bugs.launchpad.net/evergreen/+bug/635121 reported
that call numbers were being displayed in the order that they had been
added to the database, rather than in sorted call number label order.
Although I have been unable to reproduce this problem on two different
test systems, the patch he provided for 1.6.1 (which fixes the problem on their
test system) shouldn't hurt other systems.
7900914...
by
dbs <dbs@dcc99617-32d9-48b4-a31d-7c20da2025e4>
Prevent ingest errors when asset.uri ID value outstrips asset.call_number
We were basing IDs in asset.uri on the max ID of asset.call_number,
which occasionally led to major ingest problems as attempts to insert
the next ID into asset.uri failed because that ID already existed. Using
the max ID from asset.uri for asset.uri inserts seems to make more sense
and does resolve that problem.
The bigger problem of not using the sequences that are already on these
tables to generate the IDs will not be an issue in 2.0, when we move to
in-database ingest and can use the normal lastval() approach to populate
asset.uri_call_number_map with the new values.
