Add Endpoint to Get Metadata History by Id

@jmfee @pcain for discussion

It would be very useful to be able to query the "metadata_history" table in the same way that we make GET requests to the "metadata" table.

metadata table:

• metadata/ (all) use params
• metadata/:id (single)

metadata_history table (current):

• metadata/:id/history (return metadata[], based on metadata.id)
• *new endpoint* (return metadata, based on metadata_history.id)

I don't think we need to ability to query against all MetadataQueryParams on the "metadata_history" table, but it would be nice to have an endpoint that allows us to get the metadata history record based on metadata_history.id. This would allow us to build our application on the front-end in a similar manner when requesting old versions to edit.

Proposed Changes:
metadata_history table (option 1)

• metadata/history/ use params, get single record with { "id": 1 }
• metadata/history/:id use metadata_id, query for all records with metadata_id

metadata_history table (option 2)

• metadata/:metadata_id/history (current, get by metadata_id)
• metadata/:metadata_id/history/:id (new, get my id)

added Discuss label

changed the description

@ehunter I don't think I clearly understand the usage case of this feature. If we wanted to revert metadata back to an old version then I could see this being needed. If that is not the intention, then I would be concerned about repeated copies that didn't actually originate from the base metadata. How do you think we could handle what the "current" version of the historical metadata is when it is amongst other versions of the same base metadata?

@pcain

All I am suggesting here is that we be able to make GET request for a record in the metadata_history table using the metadata_history.id. Right now the only way we can query this table is with the metadata_history.metadata_id

I'm open to this but have a couple questions. The metadata history will already have been loaded at this point, right? but is navigating to a separate page and you want to make a new request to load the historic details?

I guess it's not as important of a feature for metadata history. However, this is our workflow when working with new metadata we:

1. request all metadata (metadata[]), user sees all the metadata in a list
2. user selects individual metadata from list to edit (metadata.id)
3. this triggers GET request to get metadata details (/metadata/:id)

When the user clicks on a metadata record to "review/edit" we already have that metadata record in state, so we could just grab it from state. However, we make an additional GET request (/metadata/:id) to ensure that the data stored in state has not become stale (because someone else reviewed it).

I guess this isn't much of an issue when a user wants to edit an older version of the metadata. The metadata stored in metadata_history will never change, so if they are working in the user interface there is no way that the data would have been changed out from underneath them.

This can be closed, I just wanted to document what I was thinking.

@ehunter: We may want to display/query a subset of history attributes, especially if history is large, so this is still a reasonable feature

@ehunter What attributes would be most helpful? I was thinking id, Updated by/time, status, station and category? Any others that you had in mind?

@ehunter , @pcain : how about

• /metadata/:id/history

  history for a specific metadata.

• /metadata/history/:id

  return specific history record, or 404 if not found.

• (not needed yet, can implement later) /metadata/history

  search metadata history using MetadataQuery parameters

This sounds fine to me, I will open up an issue for querying but will link this issue in !83 (merged) for id requests

closed

reopened

mentioned in issue #26 (closed)

mentioned in merge request !83 (merged)

added In Review label

removed Discuss label

closed with merge request !83 (merged)

mentioned in commit c8cff24f

removed In Review label