Re: [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.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 +
> From: "Detelich, Alicia" 
> To: Archivesspace Users Group
> 
> 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:  on behalf
> of Rachel Donahue 
> 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 +
> From: "Mayo, Dave" 
> To: Archivesspace Users Group
> 
> 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

Re: [Archivesspace_Users_Group] Oddities when updating Agents via the API

[Mayo, Dave]

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

From:  on behalf of 
Rachel Donahue 
Reply-To: Archivesspace Users Group 

Date: Friday, October 11, 2019 at 11:52 AM
To: "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

--

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.
___
Archivesspace_Users_Group mailing list
Archivesspace_Users_Group@lyralists.lyrasis.org
http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group

Re: [Archivesspace_Users_Group] Oddities when updating Agents via the API

[Detelich, Alicia]

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:  on behalf of 
Rachel Donahue 
Reply-To: Archivesspace Users Group 

Date: Friday, October 11, 2019 at 11:52 AM
To: "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

--

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.
___
Archivesspace_Users_Group mailing list
Archivesspace_Users_Group@lyralists.lyrasis.org
http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group