Versioning

[tpendragon]

@newmanld requested an MVP use case around versioning.

Added 01/25/19:

If this is going to be able to be used in every adapter, I just want to condense some questions (including the useful original ones from @jcoyne):

1. What are the boundaries of the version? If I version resource A, which has a child B, and then B changes, does the old version of A point to the newest B, or to an old version of B?
   a. How does this work in Fedora?
2. What kind of API is useful here? It's pretty trivial to create a new Valkyrie::Resource with the same properties as the previous, and just re-save it with a link forward to the existing resource. However, this wouldn't use the Fedora versioning API unless we reserved that version property somehow and added special functionality to the Fedora adapter.
3. ONLY Fedora has a versioning API. Does it work how users actually want versioning to work? If we define the above two questions and implement them, can we just use the versioning API as-is, or will we need further modifications to how we use it?
   a. Also, would this mean we'd need a F4 and F5 adapter, since those changes are pretty significant?
4. What does "versioning" a binary resource mean? Does the ID need to stay the same? What's the use case here? What's the difference between versioning a binary resource and uploading a new binary resource with a new ID, and updating the link in the container metadata resource?

[jcoyne]

What does Versioning mean? Why is it important to have it in Valkyrie *? Could this be a use case where versioning takes place at a different level of the stack (e.g. push to fedora, export a bag)?

1. Versioning binaries?
2. Versioning metadata resources?
3. Versioning object graphs (e.g. object and it's contained file metadata OR collection and it's objects + file metadata)? How do you define the boundary of a graph?

* I'm not saying we shouldn't have it, but we ought to articulate our answers to these questions.

[tpendragon]

@jcoyne Totally, thanks for expanding on that. I'm of the opinion that if it's a hard thing which Hyrax supports in the UI then we should see how hard it is to support.

[tpendragon]

In Hyrax what this does is version the binary content and its associated metadata. Do we do this at all? Can we add a "Version" button that's adapter agnostic and solves this use case?

[newmanld]

‘Versions’ in Hyrax (unless it has changed in 2.x) is an option on the Actions drop down menu within an Item list on the Work show page. On the subsequent versioning display, there is an option to Upload a new version (replace an existing file) or Restore a Previous Version (return to an earlier version of the file). Being able to restore depends on the user having seen this dialogue. In other words, I think that if a user deletes a file and uploads a file with the same file name, as two separate actions and without using the ‘upload a new version’ function, Hyrax doesn’t maintain this information as versions. @tpendragon could you explain more what you mean by adapter agnostic? Thanks.

[escowles]

@newmanld By "adapter agnostic" we mean it should work whether you store your files on disk or in Fedora, or any other storage adapter that might be developed.

[newmanld]

That makes sense. Thanks @escowles!

[escowles]

Strawdog versioning API proposal:

1. Both StorageAdapters and MetadataAdapters should have a method to create a snapshot of an existing resource
2. FileNodes and Valkyrie::Resources can have a property that contains pointers to the versions created (as an array? just link to the most recent version which could link to the previous version, etc.?)

• The version pointer property would let you list the versions
• Normal load/save functionality could be used to view/delete/restore the previous versions

[tpendragon]

The useful API to be in Valkyrie is still up in the air at this point. Marking this as a question for discussion.

[awead]

We have use cases for versioning, and I'm wondering if we could achieve something with versioned attributes in a resource. A naive solution would be a versioned attribute as a hash with timestamped keys. Any versioned attributes would all have the same timestamp key from the point at which it was saved. A "snapshot" of a resource or set of resources would be those saved with the same timestamps. It also allows you to have some attributes not versioned.

You could effect a kind of versioning of files this way, provided that a file's identifier was an attribute of a Valkyrie resource. I imagine most implementations will have some kind of wrapping resource that contains the file itself and other metadata. The new version of the file would be persisted with a new identifier, and previous identifiers would be tracked as versioned attributes of the file's containing resource.