[Archivesspace_Users_Group] splitting containers encoded as box:folder

[Mark Cooper]

Hi Steve,


It's definitely a good idea to be very cautious with SQL updates to the ArchivesSpace db, but in this case I'd argue it's appropriate, as well as being the most straightforward path. There's always more than one way to do it but it's something along the lines of:


Create a tmp table of the container ids and split indicator_1 (ind1, ind2) values where type_1 is box:folder

Update container type_1 to box where id is in your tmp box:folder table

Update container type_2 to folder where id is in your tmp box:folder table

Use the matching id in the tmp table to update indicator_1 -> ind1, indicator_2 -> ind2.

Reindex (you can be precise about it by looking up related records through container -> instances and updating their system_mtime, but just doing everything is easiest).


Best,

Mark


Mark Cooper
Technical Lead, Hosting and Support
LYRASIS
email: mark.cooper at lyrasis.org
skype: mark_c_cooper
________________________________
From: archivesspace_users_group-bounces at lyralists.lyrasis.org <archivesspace_users_group-bounces at lyralists.lyrasis.org> on behalf of Majewski, Steven Dennis (sdm7g) <sdm7g at eservices.virginia.edu>
Sent: Wednesday, November 16, 2016 8:30:30 AM
To: Archivesspace Users Group
Subject: [Archivesspace_Users_Group] splitting containers encoded as box:folder


We have thousands of archival_objects where container type_1 is encoded as “box:folder” ( with some variation of case and punctuation ) and with the value encoded in a similar manner ( i.e. “1:1” )

This was our normal encoding practice in EAD. I have since added code to our pre-import stylesheet to split these into separate container elements, but these records have already been imported previous to discovering this issue.

It would seem easier to fix and split these values before doing the 1.5.1 migration.
In test migrations, the result is separate top containers for all of the
I’ve been exploring my options for doing this.
Using the backend API would appear to be too difficult and time consuming, so I’m probably going to shutdown the servers and run the backend server from the console to run a script to convert all of the values. ( I suppose an alternative would be to do the updates directly from MySQL, but I’ve been advising others not to do this. And I probably feel more comfortable doing it in ruby thru the sequel GEM than directly in MySQL. And I don’t trust EAD roundtripping in ASpace enough to try to export/fix/import via EAD. )

Just wondering if anyone else has had to deal with a similar problem and how it was managed?


— Steve Majewski



_______________________________________________
Archivesspace_Users_Group mailing list
Archivesspace_Users_Group at lyralists.lyrasis.org
http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20161116/62c4e883/attachment.html>