Bug #10602

CSV import fails when using the accessionNumber column to link new descriptions to existing accession records

Added by Dan Gillean over 5 years ago. Updated over 5 years ago.

Status:VerifiedStart date:11/22/2016
Priority:MediumDue date:
Assignee:Dan Gillean% Done:

0%

Category:CSV import
Target version:Release 2.3.1
Google Code Legacy ID: Tested version:2.3, 2.4
Sponsored:Yes Requires documentation:

Description

First reported via the User Forum - CLI import in AtoM 2.3 (I think, could be 2.2). Reproduced in qa/2.4.x via user interface import testing as well.

To reproduce

  • Create a new accession record, or go and find the accession number of an existing accession record.
  • Take one of the archival description import CSVs (e.g. the ISAD 2.3 CSV import example), and add a new column, titled "accessionNumber" to the CSV.
  • Add the accession number recorded above in step 1 to the new column as a value for the example description in the CSV.
  • Save your changes (remember - must be CSV format, UTF-8 encoded, unix-style line endings, etc)
  • Import the new archival description CSV

Resulting error

Import crashes. Error returned:

Unable to execute INSERT statement. [wrapped: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '2013-12-20/5' for key 'accession_U_1']

Expected result

Import proceeds successfully. New archival descriptions are linked to existing accession records.

History

#3 Updated by Steve Breker over 5 years ago

Previously, the import program would attempt to find the accession identifier
in the keymap table, and if that failed it would create a new accession
record with that identifier. In the case where the keymap record could not be
found, but the accession record already existed, an error would display and
the import would halt.

I have changed the logic so that the import will try to find a corresponding
keymap record to use and if that fails, it will try to directly find an
accession record in the database. If keymap search is successful, that
accession record will be used. If the secondary lookup against the database
is successful, then that accession record will be used. If both keymap and
direct lookup fail, a new accession record will be created.

#4 Updated by Steve Breker over 5 years ago

  • Status changed from New to Code Review
  • Assignee set to Nick Wilkinson

#5 Updated by Dan Gillean over 5 years ago

  • Target version set to Release 2.4.0
  • Sponsored changed from No to Yes
  • Requires documentation set to Yes

Adding to 2.4 as target version. Adding a note to add documentation, as I think it might help our users to explain Steve's matching criteria in note 3 above in the docs.

#6 Updated by Jesús García Crespo over 5 years ago

This looks good to me but I'm not familiar with this part of the application so I'd suggest another developer to take an extra look.

#7 Updated by Steve Breker over 5 years ago

PR should go into 2.4 and then cherry pick to stable/2.3.x after QA/Review in 2.4.

#8 Updated by Nick Wilkinson over 5 years ago

  • Assignee changed from Nick Wilkinson to Mike Cantelon

#9 Updated by Mike Cantelon over 5 years ago

  • Status changed from Code Review to Feedback
  • Assignee changed from Mike Cantelon to Steve Breker

Hi Steve... the PR looks good to me!

#10 Updated by Steve Breker over 5 years ago

  • Status changed from Feedback to QA/Review
  • Assignee changed from Steve Breker to Nick Wilkinson

I have merged this change to qa/2.4.x. Ready for QA.

#11 Updated by Nick Wilkinson over 5 years ago

  • Assignee changed from Nick Wilkinson to Dan Gillean

#12 Updated by Dan Gillean over 5 years ago

  • Status changed from QA/Review to Verified
  • Target version changed from Release 2.4.0 to Release 2.3.1

Looks good!

Apparently we're backporting this one for 2.3.1, so I've updated the target version.

#13 Updated by Steve Breker over 5 years ago

Cherry-picked to stable/2.3.x.

#14 Updated by Dan Gillean over 5 years ago

  • Requires documentation deleted (Yes)

Also available in: Atom PDF