Hi all,
We’ve noticed that in our test migration from ArchivesSpace version 2.8.0 to
3.0.1 that the agent migration was sometimes creating two separate structured
dates based on whether there was an existing date expression or not in the
dates of existence section.
Here is the JSON before migration:
"dates_of_existence": [
{
"lock_version": 0,
"expression": "1915-2017",
"begin": "1915",
"end": "2017",
"created_by": "pgalligan",
"last_modified_by": "pgalligan",
"create_time": "2019-12-04T14:24:11Z",
"system_mtime": "2019-12-04T14:24:11Z",
"user_mtime": "2019-12-04T14:24:11Z",
"date_type": "range",
"label": "existence",
"jsonmodel_type": "date"
}
],
Here is the JSON post-migration:
"dates_of_existence": [
{
"create_time": "2021-06-16T19:12:16Z",
"system_mtime": "2021-06-16T19:12:16Z",
"user_mtime": "2021-06-16T19:12:16Z",
"lock_version": 0,
"date_label": "existence",
"date_type_structured": "single",
"jsonmodel_type": "structured_date_label",
"structured_date_single": {
"date_expression": "1915-2017",
"create_time": "2021-06-16T19:12:16Z",
"system_mtime": "2021-06-16T19:12:16Z",
"user_mtime": "2021-06-16T19:12:16Z",
"lock_version": 0,
"date_role": "begin",
"date_standardized_type": "standard",
"jsonmodel_type": "structured_date_single"
}
},
{
"create_time": "2021-06-16T19:12:16Z",
"system_mtime": "2021-06-16T19:12:16Z",
"user_mtime": "2021-06-16T19:12:16Z",
"lock_version": 0,
"date_label": "existence",
"date_type_structured": "range",
"jsonmodel_type": "structured_date_label",
"structured_date_range": {
"begin_date_standardized": "1915",
"end_date_standardized": "2017",
"create_time": "2021-06-16T19:12:16Z",
"system_mtime": "2021-06-16T19:12:16Z",
"user_mtime": "2021-06-16T19:12:16Z",
"lock_version": 0,
"begin_date_standardized_type": "standard",
"end_date_standardized_type": "standard",
"jsonmodel_type": "structured_date_range"
}
}
],
It also seems to be creating a structured singular date instead of a date
range. It’s parsing the expression correctly into separate dates, but it’s
entirely unnecessary and creates and incorrect duplication.
This seems like a bug and would stop us from updating because it’d be a hassle
to go in and remove these.
Is this intended behavior for this migration? There may be something I’m not
understanding about MARC or EAC-CPF that makes this desirable, but it seems
like a bug to me.
Thanks,
Patrick Galligan
Rockefeller Archive Center
_______________________________________________
Archivesspace_Users_Group mailing list
[email protected]
http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
