Bug #5560
Updated by Tom Clegg about 9 years ago
Problems with the @old_attributes@ and @new_attributes@ hashes 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).
* The @*_attributes@ hashes 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 @select@ to avoid retrieving _any_ properties).
* Even the associated @old_etag@ and @new_etag@ fields are not indexable or searchable.
Possible approach:
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).