Modified On should not change when file is deleted.

Description

If the current version is deleted, the ModifiedOn date of the previous version is updated to today's date. I think this is not ideal because we are losing information about the date of change. The file itself was not modified.

Environment

None

Activity

Show:
Ryan Luce
December 20, 2019, 5:52 PM

Is the modifiedon field referring to a specific version - or is it just to the overall file (effectively describing all versions)?

Bruce Hoff
December 20, 2019, 9:43 PM

> Is the modifiedon field referring to a specific version - or is it just to the overall file

That's a good question. The answer is, it's the former. For example, consider this file
https://www.synapse.org/#!Synapse:syn2245702
Click on File Tools > Version History to see that there are two versions. The first has "modifiedOn"="
2018-03-14", the second, "2018-09-13". Now retrieve the first version programmatically and check the modified on date:

So you can see that modifiedOn describes the version. I think what might be seeing is that the version is deleted and then, in some corollary activity, the previous version (now the current/latest version) gets modified, bumping the time stamp to the present time. To test this I visited
https://www.synapse.org/#!Synapse:syn15588579
which has just one version, modifiedOn=2018-08-06. Now I upload a new file version and confirm that there are two versions, the second having modifiedOn=
2019-12-20. Now I delete the new (second) version and see that the first version has modifiedOn=
2019-12-20. Yep, it's just as experienced.

Bruce Hoff
December 20, 2019, 9:48 PM

You can see in our code base that bumping the time stamp of the new latest version is done explicitly when deleting a version:
https://github.com/Sage-Bionetworks/Synapse-Repository-Services/blob/f629d307a414f8276969cfac0310ec9cf8b550d0/services/repository-managers/src/main/java/org/sagebionetworks/repo/manager/NodeManagerImpl.java#L282
So we must have felt that this was the right behavior when implementing version deletion. do you recall the rationale? shall we change the behavior?

Ryan Luce
December 20, 2019, 9:55 PM

Seems like we should change the behavior, but I’m curious if John (or others) remember the rationale

Bruce Hoff
December 20, 2019, 11:35 PM

Per changing modifiedOn is intertwined with marking the object as changed for optimistic concurrency and migration. Disentangling the two is possible but awkward so we should be sure about the need not to change modifiedOn before going forward.

Assignee

John Hill

Reporter

Kelsey Montgomery

Labels

None

Validator

Bruce Hoff

Development Area

None

Release Version History

None

Priority

Major
Configure