Topic on Talk:RESTBase/StorageDesign

As described, the timeline scheme does not seem to offer guarantees for the availability of old revisions. In terms of the schema, this corresponds to a "latest_hash" revision retention policy with grace_ttl.

Use case: A user edits an older revision using VisualEditor.

Issue: As described, renders of old revisions can be deleted at any time, irrespective of when they were actually rendered last. This means that the edit in the use case can fail, as original HTML or metadata needed for successful editing might not be available any more.

I don't think I understand your concern. Past revisions (and renders) will exist for a period of at least the TTL specified after they have been superseded by something newer. This is the reason for the timeline structure, to index revisions by timestamp so that we can choose a revision ID to use in the range delete, on the basis of its age.

If you're talking about a user attempting to edit an arbitrarily older revision (which I understand is an actual use case), neither this (nor the other strategy) will support it; This is storage of current revisions only.

The requirement is to store current revisions long term, and old revisions for at least TTL after they were requested. In schema terms, the requirement is to support latest_hash with TTL. The prototype multi-table implementation supports this using TTLs and separate tables. What it does not implement yet is TIMESTAMP or byte order precedence for latest updates.

The timeline algorithm does not seem to take renders for old revisions into account, as the timeline is purely based on edits, and not on renders.