Trying to Find File Path of CSV File

[Laura Jones]

How do I find the filepath to a CSV file I imported through the user interface? I'm trying to update existing data using --roundtrip but don't know how to check the filepath for my existing CSV so it can be updated. 

Thanks!

[Dan Gillean]

Hi Laura, 

A CSV is only temporarily used in AtoM to write metadata - it's not stored in AtoM after being uploaded. So when you perform an update, you are not finding the original CSV and updating it, so much as you are using the metadata in your new CSV to find and update related records in AtoM from previous imports. So, you don't need a file path to where any previous CSV might be located. 

This is part of why doing CSV updates in AtoM - particularly the matching part - is currently hard, and why we added the --roundtrip option in the command-line to make it easier (something I hope we can add as an option in the user interface in the future as well). 

How the roundtrip option works in AtoM

You should only use this option if you have exported a CSV from your AtoM instance, made some updates to the metadata in the CSV, and now want to re-import it as an update to those records. 

When you import a record in AtoM, each row in your CSV is written to the various tables in AtoM's MySQL database - most fields go in the information_object and information_object_i18n tables (those used to store archival description metadata), but in some cases, your metadata is spread across a few database tables - for example, notes (like Archivists Note, or any of the more specific RAD or DACS note fields) are stored in a separate linked table. However, before this, all main records first get an entry in the base object table, and MySQL automatically assigns each one a unique ID - i.e. the objectID. 

Now, when you perform a CSV export from AtoM, it is this object ID value that populates the legacyID column of the resulting CSV. This is so it can be used as a unique value if you are ever migrating your metadata to a different system (the legacyId column in our CSVs was first added to help us migrate user metadata from other legacy systems INTO AtoM). 

Normally, trying to match a row of metadata in a CSV with a description in AtoM can be a tricky business - after all, you might have many records called "Correspondence", and/or many records with an identifier or 001 - all possibly belonging to the same archival institution. Ensuring we have the right record can be tricky, which is what the --roundtrip option aims to make easier. 

when the --roundtrip option is used with the CSV import command-line task, all other matching criteria are ignored, and only the object ID values in the legacyId column are used for matching criteria. Because object ID's must be unique in MySQL, it's all or nothing - either a 100% match, or the wrong record. 

So to summarize - to use the roundtrip option:

• Find the descriptions you want to update in AtoM and add them to the clipboard. 
• Export them as a CSV
• Make the updates you want in the CSV - see the documentation for an overview of what you can and can't update
• Just make sure you DO NOT CHANGE THE legacyId values for any row!
• Add your CSV to the AtoM server
• Import the CSV from the command-line, using the --roundtrip path. 

So what's the filepath I need in the CSV import CLI task?

If you're using the command-line to do an import, that means you have access to the server where AtoM is installed. To import a CSV using the command-line interface, you need to place the CSV somewhere AtoM can access it - for example, just sticking it right in AtoM's root directory is fine, since you can delete it out of there after you've confirmed the import was successful. 

So, if your AtoM installation follows our recommended installation instructions and the root directory is /usr/share/nginx/atom, you could add your CSV (let's call it my-updates.csv) in the root directory, like so:  

• /usr/share/nginx/atom/my-updates.csv

The path in the command-line task is to tell AtoM where the CSV with the updated metadata is located. So running the task might look something like this: 

• php symfony --update="match-and-update" --skip-unmatched --roundtrip csv:import /usr/share/nginx/atom/my-updates.csv
  

See: https://www.accesstomemory.org/en/docs/2.6/admin-manual/maintenance/cli-import-export/#csv-import-descriptions-cli

Once your import is done, that CSV will still be located at /usr/share/nginx/atom/my-updates.csv, although it's no longer needed - so you can delete it, copy it back out to another location, ignore it, etc. 

Finally, in case you want to better understand why CSV import updates are so damn confusing in AtoM right now, I've tried to explain the background a bit more in these previous forum threads: 

• https://groups.google.com/g/ica-atom-users/c/HMoN4tEuJ10/m/n4e1gqftBQAJ
  
• https://groups.google.com/g/ica-atom-users/c/bCWYFIkLCRs/m/7QTPfLnQAQAJ

Hope this helps, 

Dan Gillean, MAS, MLIS
AtoM Program Manager
Artefactual Systems, Inc.
604-527-2056

@accesstomemory

he / him

On Fri, Jul 15, 2022 at 12:06 PM Laura Jones <styx...@gmail.com> wrote:

How do I find the filepath to a CSV file I imported through the user interface? I'm trying to update existing data using --roundtrip but don't know how to check the filepath for my existing CSV so it can be updated. 

Thanks!

--
You received this message because you are subscribed to the Google Groups "AtoM Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ica-atom-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/76e45b93-9117-47a2-9f0b-d95e79dd81e5n%40googlegroups.com.