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.dona...@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.detel...@yale.edu> > To: Archivesspace Users Group > <archivesspace_users_group@lyralists.lyrasis.org> > Subject: Re: [Archivesspace_Users_Group] Oddities when updating Agents > via the API > Message-ID: <5604120b-a726-4ed2-8537-0b94a6b49...@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-boun...@lyralists.lyrasis.org> on behalf > of Rachel Donahue <rachel.dona...@lac-group.com> > Reply-To: Archivesspace Users Group < > archivesspace_users_group@lyralists.lyrasis.org> > Date: Friday, October 11, 2019 at 11:52 AM > To: "archivesspace_users_group@lyralists.lyrasis.org" < > archivesspace_users_group@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_m...@harvard.edu> > To: Archivesspace Users Group > <archivesspace_users_group@lyralists.lyrasis.org> > Subject: Re: [Archivesspace_Users_Group] Oddities when updating Agents > via the API > Message-ID: <50e41cb5-5a5c-4359-b742-bdf5c9787...@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 > > >
_______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group@lyralists.lyrasis.org http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group