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: [email protected] skype: mark_c_cooper ________________________________ From: [email protected] <[email protected]> on behalf of Majewski, Steven Dennis (sdm7g) <[email protected]> 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 [email protected] http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
_______________________________________________ Archivesspace_Users_Group mailing list [email protected] http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
