[Archivesspace_Users_Group] Oddities when updating Agents via the API

[Rachel Donahue]

Alicia and Dave,

Thank you so much for your help! I was thrown by telephone having it's own
URI, but I guess I'll just have to accept the new creation dates. We're
using a hosted instance, so I unfortunately don't have MySQL access.

Dave-- the  JSON payload already contains the original created_by
information, so I don't think maually setting it by API is going to work.
Like I said, not make or break, just nice-to-have. The information for
subrecords doesn't even show in the staff interface, so I'm likely the only
one who would ever notice that it's happening.

Best,
Rachel

--

Please note that I currently *do not have access to ARS email*. If you need
to contact me, use my LAC address: rachel.donahue at lac-group.com

The information contained in this e-mail message is confidential. If you
are not the intended recipient, any dissemination or copying is strictly
prohibited. If you think that you have received this e-mail message in
error, please contact the sender.



>
> Message: 16
> Date: Fri, 11 Oct 2019 16:17:07 +0000
> From: "Detelich, Alicia" <alicia.detelich at yale.edu>
> To: Archivesspace Users Group
>         <archivesspace_users_group at lyralists.lyrasis.org>
> Subject: Re: [Archivesspace_Users_Group] Oddities when updating Agents
>         via the API
> Message-ID: <5604120B-A726-4ED2-8537-0B94A6B49194 at yale.edu>
> Content-Type: text/plain; charset="utf-8"
>
> Hi Rachel,
>
> Basically, what you are seeing is that whenever a record is posted, all of
> its subrecords are deleted and recreated, even if no changes are made to
> the subrecords themselves. When this happens a new database identifier,
> create time, lock version etc. are assigned to each subrecord. I don?t
> think it?s a bug, per se, but it is an odd behavior that has come up
> numerous times in my work as well.
>
> I am not sure why the decision to design subrecords that way was made by
> the original developers of the application (if anyone has thoughts please
> let me know!), nor do I have a sense of the amount of work/consequences
> involved in updating the application so that subrecords are persistent.
>
> There isn?t a way to only post the changing fields via the API, since only
> top-level records (resources, archival objects, etc.) have their own URIs.
> An alternative solution would be to do a (very careful!) database update to
> the relevant field(s) in the relevant name table(s).
>
> Hope this helps,
>
> Alicia
>
> Alicia Detelich
> Archivist
> Manuscripts and Archives
> Yale University Libraries
>
> From: <archivesspace_users_group-bounces at lyralists.lyrasis.org> on behalf
> of Rachel Donahue <rachel.donahue at lac-group.com>
> Reply-To: Archivesspace Users Group <
> archivesspace_users_group at lyralists.lyrasis.org>
> Date: Friday, October 11, 2019 at 11:52 AM
> To: "archivesspace_users_group at lyralists.lyrasis.org" <
> archivesspace_users_group at lyralists.lyrasis.org>
> Subject: [Archivesspace_Users_Group] Oddities when updating Agents via the
> API
>
> Hi all,
>
> I'm running some bulk updates to Agents (in this case people) via the API
> and noticed some rather odd changes to sub-records when I check the JSON
> after successfully running the update.
>
> 1. Every sub-record (e.g. names, telephones) has replaced "created_by"
> with the user authenticated by the API and create_time with the time of the
> API call. The Agent itself retains its created_by and time, thankfully, but
> all the bits and pieces lose it.
> 2. Possibly related to this, a new telephone number is created even though
> nothing about the phone number has changed. (e.g. what was /telephone/99 is
> now /telephone/204)
> 3. The lock_version for the sub-records isn't changing from 0.
>
> The only thing changing in these updates is the name source and we're
> using ArchivesSpace 2.6.0. I have been reposting the entire object in the
> update--is it possible to post *only* the changing fields and perhaps avoid
> the problem?
>
> While this isn't a make-or-break problem, I'd really like to retain the
> created_by information for names, as it is often *not* the same as the
> person who created the initial record. I'm also not sure if this is a bug
> or something I'm doing wrong. Any insights would be much appreciated!
>
> Best,
> Rachel
>
>
> Message: 18
> Date: Sun, 13 Oct 2019 20:52:04 +0000
> From: "Mayo, Dave" <dave_mayo at harvard.edu>
> To: Archivesspace Users Group
>         <archivesspace_users_group at lyralists.lyrasis.org>
> Subject: Re: [Archivesspace_Users_Group] Oddities when updating Agents
>         via the API
> Message-ID: <50E41CB5-5A5C-4359-B742-BDF5C9787A2E at harvard.edu>
> Content-Type: text/plain; charset="utf-8"
>
> There are a lot of sub-records in ASpace that are essentially treated as
> ephemeral but which have full concrete tables backing them; they?re not
> addressable in the system, their representations in the JSONModel are as
> primitive values (strings, array of strings, etc) rather than objects,
> etc.  Instances are kind of this way ? you can?t grab an instance, only the
> things attached to it, but it has a database ID, etc.
>
> You _might_ be able to insert refs to the subrecords that aren?t changing,
> rather than the values/records themselves?  That _might_ keep the values
> the same, but I?m not sure it?ll be legal everywhere.  You could also try
> explicitly setting created_by and created_at; I am at a conf but could poke
> at this later (maybe tonight or tomorrow) if you?ll remind me.
>
> --
> Dave Mayo (he/him)
> Senior Digital Library Software Engineer
> Harvard University > HUIT > LTS
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20191015/0ffe5bf9/attachment.html>