Re: [Archivesspace_Users_Group] Archivists' Toolkit to ArchivesSpace Migration Workflow

[Corey Schmidt]

Noah,

Thank you for the advice!

I have copies of databases made, but I do not have access to the MySQL 
databases directly, as that is being hosted by a third-party. If I can get 
access to them, I should be able to experiment with cleaning them up directly 
with SQL. I have some experience working with SQLite, so it shouldn’t be too 
hard to learn. I’ll look into using Navicat too, as it seems like a pretty 
handy tool.

Thanks,

Corey

From: archivesspace_users_group-boun...@lyralists.lyrasis.org 
 On Behalf Of Noah 
Huffman
Sent: Wednesday, December 11, 2019 12:13 PM
To: Archivesspace Users Group 
Subject: Re: [Archivesspace_Users_Group] Archivists' Toolkit to ArchivesSpace 
Migration Workflow

[External Sender]
Hi Corey,

I’d highly recommend doing as much data cleanup as possible directly in your AT 
database, particularly extent type values, container type values, etc. Of 
course, be sure to back up your database☺

If you’re comfortable writing/running SQL queries, you can connect a free 
database management tool like MySQL Workbench to your AT backend database to 
review/clean your data in bulk.

Alternatively, there are other database management tools like Navicat that let 
you review and edit the backend database tables in a graphical spreadsheet-like 
editor (without having to write SQL). I used Navicat to clean up a lot of AT 
data prior to migrating to ASpace. If you can do all your cleanup in the 14-day 
trial period, then you don’t have to buy the software!

Best of luck,
-Noah


Noah Huffman
Archivist for Metadata, Systems, and Digital Records
David M. Rubenstein Rare Book & Manuscript Library
Duke University | 919-660-5982
http://library.duke.edu/rubenstein/


From: 
archivesspace_users_group-boun...@lyralists.lyrasis.org
 
mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org>>
 On Behalf Of Corey Schmidt
Sent: Wednesday, December 11, 2019 10:20 AM
To: Archivesspace Users Group 
mailto:archivesspace_users_group@lyralists.lyrasis.org>>
Subject: Re: [Archivesspace_Users_Group] Archivists' Toolkit to ArchivesSpace 
Migration Workflow

Mark,

Thank you so much for the wonderful info!

I am just beginning to dive into the data, but I will look out for linked cross 
references and the creation of new data in ArchivesSpace. We don’t have any 
EADs that exist outside of AT so far as I’m aware, so the process of exporting 
from AT, cleaning up, then reimporting might be unnecessary as you pointed out. 
If it’s possible to update the AT database directly, that would save so much 
time and effort. The articles you linked were very helpful and should give me a 
basis for how to approach this and other potential problems.

Thanks again!

Corey
From: 
archivesspace_users_group-boun...@lyralists.lyrasis.org
 
mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org>>
 On Behalf Of Custer, Mark
Sent: Tuesday, December 10, 2019 6:33 PM
To: Archivesspace Users Group 
mailto:archivesspace_users_group@lyralists.lyrasis.org>>
Subject: Re: [Archivesspace_Users_Group] Archivists' Toolkit to ArchivesSpace 
Migration Workflow

[External Sender]
Corey,

First of all, welcome to the ArchivesSpace community!  Your project will 
definitely make you an ArchivesSpace expert in no time.

Glancing at your workflow document, it looks like you’ve got all of your bases 
covered.  I would strongly suggest running the AT to ASpace migration a couple 
of times (just to get familiar with it), and also to get a few other folks to 
help spot-check the results (the more eyes / institutional experience the 
better), before you go ahead and do the final migration.  It’s a been a long 
while since I used that tool.  I do remember, though, that when we started 
testing it out, the tool couldn’t be used to migrate multiple AT databases into 
a single ASpace database.  That feature was added a long time back, though, so 
you *should* be good to go with migrating your two AT databases into a single 
version of ASpace, which I would highly recommend.

Regarding the AT to ASpace migration tool, just off the top of my head, I’d 
also add:


  1.  if you have linked cross references in your current EAD files, you’ll 
either want to make sure to run the migration with the “-refid_original” 
parameter, or set aside some time after the migration to go back and update 
those linked cross references (during the migration, all of the IDs in the AT 
for the notes and components will be replaced with ASpace IDs, so if you have 
cross references embedded in your finding aids, those will be broken).  We had 
a lot of cross references in our source files in the AT, so we opted with that 
first option, as you can see here:  

Re: [Archivesspace_Users_Group] Archivists' Toolkit to ArchivesSpace Migration Workflow

[Corey Schmidt]

Mark,

Thank you so much for the wonderful info!

I am just beginning to dive into the data, but I will look out for linked cross 
references and the creation of new data in ArchivesSpace. We don’t have any 
EADs that exist outside of AT so far as I’m aware, so the process of exporting 
from AT, cleaning up, then reimporting might be unnecessary as you pointed out. 
If it’s possible to update the AT database directly, that would save so much 
time and effort. The articles you linked were very helpful and should give me a 
basis for how to approach this and other potential problems.

Thanks again!

Corey

From: archivesspace_users_group-boun...@lyralists.lyrasis.org 
 On Behalf Of Custer, 
Mark
Sent: Tuesday, December 10, 2019 6:33 PM
To: Archivesspace Users Group 
Subject: Re: [Archivesspace_Users_Group] Archivists' Toolkit to ArchivesSpace 
Migration Workflow

[External Sender]
Corey,

First of all, welcome to the ArchivesSpace community!  Your project will 
definitely make you an ArchivesSpace expert in no time.

Glancing at your workflow document, it looks like you’ve got all of your bases 
covered.  I would strongly suggest running the AT to ASpace migration a couple 
of times (just to get familiar with it), and also to get a few other folks to 
help spot-check the results (the more eyes / institutional experience the 
better), before you go ahead and do the final migration.  It’s a been a long 
while since I used that tool.  I do remember, though, that when we started 
testing it out, the tool couldn’t be used to migrate multiple AT databases into 
a single ASpace database.  That feature was added a long time back, though, so 
you *should* be good to go with migrating your two AT databases into a single 
version of ASpace, which I would highly recommend.

Regarding the AT to ASpace migration tool, just off the top of my head, I’d 
also add:


  1.  if you have linked cross references in your current EAD files, you’ll 
either want to make sure to run the migration with the “-refid_original” 
parameter, or set aside some time after the migration to go back and update 
those linked cross references (during the migration, all of the IDs in the AT 
for the notes and components will be replaced with ASpace IDs, so if you have 
cross references embedded in your finding aids, those will be broken).  We had 
a lot of cross references in our source files in the AT, so we opted with that 
first option, as you can see here:  
https://cpb-us-w2.wpmucdn.com/campuspress.yale.edu/dist/3/30/files/2015/06/Unknown-272cqj2.png
  (that screenshot was taken by Maureen Callahan, and described in a lot of 
more detail and other invaluable advice in this blog post: 
https://campuspress.yale.edu/yalearchivesspace/2015/06/14/migration-step-by-step/)
  2.  unless things have changed, be prepared for that migration tool to 
occasionally add data where no data existed before (even when it’s not required 
to do so).  E.g. for our lists in the AT that did not have a title, after the 
migration we wound up with lists in ASpace that had a title of “Missing Title”. 
 That was something we missed early on, but later on we were able to delete all 
of those values from ASpace.  Ditto for other unexpected things, like if in the 
AT someone selected a container type of “Box” but level the container value 
blank, the AT to ASpace migration would create an auto-generated container 
number so that it could keep that container type of “Box” around without 
dropping it during the migration.  We had quite a few instances in the AT where 
someone would add “Box X, Folder”. That behaved fine in the AT, but once we 
migrated, that would turn into something like “Box X, Folder someweirdnumber” 
(ideally it would’ve just come over as “Box X”).

And unless you have EAD files that aren’t in the AT already, I don’t think that 
you should need to go the route of importing EAD into ASpace.  If you do, there 
are more issues and tricks involved there, not to mention the fact that the 
more import options you allow during the migration, the more variety you’ll 
have in the results.  That’s not to say that EAD imports are bad ASpace, since 
they’ve actually improved on the AT’s EAD import process.  Also, long after our 
migration, we still import EAD files into ASpace, especially when adding 
newly-created finding aids that are so large or complex that they’d be hard to 
create directly in ASpace. However, you’ll have to be mindful of all of the 
ways that those EAD imports can muddy up your database (the primary offender 
being the fact that the importer will add values to controlled value lists 
during the import process when it tries to parse them from free text data….  
See the comment here 
https://github.com/archivesspace/archivesspace/blob/bc675bc12b72f6fb7818aae646958c80d54ff4de/backend/app/model/backend_enum_source.rb#L16…
 In other words, free text like “2.5 Linear feet (4 boxes)” would result in a 
new extent type with a value of “Linear Feet (4 

Re: [Archivesspace_Users_Group] RuntimeError: Schema Info Mismatch

[Peter Heiner]

Apologies for sending HTML mail to the list, I have failed to set my
GMail up correctly. Reproducing in plain text for convenience.

On 10 Dec 2019 21:42, "Boggio, Jerry"  wrote:

> Could someone please provide more information on the meaning of this
> message? In particular, what is represented by the “Expected” and
> “received” values?
>
> RuntimeError: Schema Info Mismatch. Expected 97, received 120 for
> ASPACE version v2.3.0

This means that the database has at some point been updated using
ArchivesSpace 2.6.0 (you can find the corresponding schema version
number in the release notes), but a version 2.3.0 instance has now been
started over it. This happened to me some time ago when I updated a
symlink pointing to my current installation to point to the new version
but configuration management has reset it to point to the old
one.

Generally, I would recommend moving forward with the application
version and not back with the database version, even if there are
facilities to do the latter.

p
___
Archivesspace_Users_Group mailing list
Archivesspace_Users_Group@lyralists.lyrasis.org
http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group