Tags: hudmol/archivesspace
Tags
Bugfix for position calculation when bulk-updating AOs within a resource
On an `update_from_json`, the `position` property on the incoming JSON
record is a logical position (where a value of N means "I'm Nth in the
list" of siblings).
This value was incorrectly being written to the `position` column in
the archival_object table as a part of doing the update. That's
incorrect because the database column should only contain physical
positions: position keys that sort correctly but leave room for
insertions.
Generally this wouldn't matter because, after the initial update, the
`tree_nodes` code would kick in, calculate the correct physical
position for the record and update the row. But if another record's
physical position corresponded to the incoming record's logical
position, the update would throw an error like:
Duplicate entry 'root@/repositories/2/resources/102-500' for key 'uniq_ao_pos'
I was able to replicate this issue by choosing a Resource with 1000+
records underneath it and then run some code like this:
ids = ArchivalObject.filter(:root_record_id => 102).select(:id).map {|row| row[:id]}
ids.each do |id|
ao = ArchivalObject.get_or_die(id)
ao_json = ArchivalObject.to_jsonmodel(ao)
ao.update_from_json(ao_json)
end
This would blow up after around 500 iterations.
The fix is to set the updated row's physical position to what it
already was, and then use the incoming JSON's logical position to
calculate its changed position and update as required. That way we
never risk stealing another record's spot.
PreviousNext