[Archivesspace_Users_Group] Odd data modifications during aspace updates.

[James Bullen]

Hi Don,

Nested subrecords get recreated on every update. They arguably shouldn’t have those audit fields.


Cheers,
James


> On Mar 11, 2020, at 8:45 AM, Donald Mennerich <don.mennerich at nyu.edu> wrote:
> 
> Hello, 
> 
> While testing a script that was updating a resource's ead_id via the api I noticed that the timestamps for  most sub-records of the resource, e.g. instances, extents, langmaterials, etc., that wern't part of the update were havign their timesstamps, includeing create_time and created_by, updated as well. I naturally assumed there was something wrong with my code, but when we tested updating a resource record from the staff interface the same thing happening was observed. 
> 
> For example, the fields belonging to the Resource model updated as expected, the creation_time and created_by were not modified, while the last_modified_by and mtimes were:
> 
> Before
> {
>   "lock_version": 1,
>   "title": "Test Collection",
>   "publish": true,
>   "restrictions": false,
>   "created_by": "admin",
>   "last_modified_by": "user1",
>   "create_time": "2016-07-14T23:50:37Z",
>   "system_mtime": "2018-03-29T22:05:59Z",
>   "user_mtime": "2017-02-02T18:15:58Z",
>  ...
> 
> After
> {
>   "lock_version": 2,
>   "title": "Test Collection",
>   "publish": true,
>   "restrictions": false,
>   "ead_id": "test_999",
>   "created_by": "admin",
>   "last_modified_by": "user2",
>   "create_time": "2016-07-14T23:50:37Z",
>   "system_mtime": "2020-03-10T17:29:46Z",
>   "user_mtime": "2020-03-10T17:29:46Z",
> ...
> 
> 
> But in most of the subrecords of the resource the timestamps have all updated to the time of the update of the resource record. In this case the only thing that was updated was in the resource record was the eadid, but the instance subrecords had their timestamps updated even though not at all part of the update. Note that while data was changed in the sub record the lock_version is still at 0. Again, this was done with an update via the staff interface.
> 
> Before
> "instances": [
>   {
>     "lock_version": 0,
>     "created_by": "user1",
>     "last_modified_by": "user1",
>     "create_time": "2017-02-02T18:15:58Z",
>     "system_mtime": "2017-02-02T18:15:58Z",
>     "user_mtime": "2017-02-02T18:15:58Z",
>     "instance_type": "mixed_materials",
>     "jsonmodel_type": "instance",
>     "is_representative": false,
>     "sub_container": {
>       "lock_version": 0,
>       "created_by": "user1",
>       "last_modified_by": "user1",
>       "create_time": "2017-02-02T18:15:58Z",
>       "system_mtime": "2017-02-02T18:15:58Z",
>       "user_mtime": "2017-02-02T18:15:58Z",
>       "jsonmodel_type": "sub_container",
> 
> After
> "instances": [
>   {
>     "lock_version": 0,
>     "created_by": "user2",
>     "last_modified_by": "user2",
>     "create_time": "2020-03-10T17:29:47Z",
>     "system_mtime": "2020-03-10T17:29:47Z",
>     "user_mtime": "2020-03-10T17:29:47Z",
>     "instance_type": "mixed_materials",
>     "jsonmodel_type": "instance",
>     "is_representative": false,
>     "sub_container": {
>       "lock_version": 0,
>       "created_by": "user2",
>       "last_modified_by": "user2",,
>       "create_time": "2020-03-10T17:29:47Z",
>       "system_mtime": "2020-03-10T17:29:47Z",
>       "user_mtime": "2020-03-10T17:29:47Z",
>       "jsonmodel_type": "sub_container",
> 
> 
> I'm trying to determine if this is a local problem or if this is just normally how aspace manages updates, and if so is it a bug. Would someone with access to the API of their ArchivesSpace instance see if they could reproduce this? I've tested this on installations of v2.7.0 and v2.7.1.
> 
> Thanks, 
> 
> Don
> !DSPAM:5e680a81236307999538416! _______________________________________________
> Archivesspace_Users_Group mailing list
> Archivesspace_Users_Group at lyralists.lyrasis.org
> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
> 
> 
> !DSPAM:5e680a81236307999538416!

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20200311/e69c195e/attachment.html>