[DRAFT] [API] Good API for accessing the old_ and new_attributes in Logs table properties column
new_attributeshashes in the properties hash:
- They don't look quite close enough to "what the API response to GET would have looked like at the time" for clients to reuse code to interpret/display them (e.g., timestamp formats can be different, computed properties are not present, locators in manifests are not signed).
*_attributeshashes can be huge (notably for collection updates, where there are two copies of the manifest). This uses a lot of database space, and (worse) makes it very slow for clients to retrieve logs (unless they use
selectto avoid retrieving any properties).
- Even the associated
new_etagfields are not indexable or searchable.
Add a version table (either a single one, or a table per model type), indexed by etag. Store the attributes in the version table. In the logs table, just store the old and new etags. Provide a distinct API for retrieving a specific version of an object (in the usual API response format for that object type) by giving its etag. Optionally, provide an API for retrieving the logs and the object versions referenced by the logs in one request (this would be as complete as the current behavior -- but that isn't necessarily important).