rusackas commented on issue #39492: URL: https://github.com/apache/superset/issues/39492#issuecomment-4423552211
Wanted to float one more alternative approach, which is kind of "the easy version" - basically appending rows for every save of every object, with the new row adding a `previous_version_id` pointer on the new row, linking to the predecessor, and a `next_version_id` on the predecessor row, pointing forward. Then you could simply SELECT the row with no `next_version_id` or (optionally) flag it as "current". Rolling back would simply update the pointers. Simpler restore. Instead of Continuum's Reverter with its autoflush/cascade-add edge cases (and the split-revert workaround described in the SIP), restore is just updating a pointer. The historical state is already a real row — no deserialization or reconstruction needed. Potential disadvantages: No structured change records out of the box. The SIP's version_changes table (capturing "added filter X", "renamed column Y") is computed at write time so the UI can display human-readable diffs cheaply. With pure pointer chaining, you'd either need to diff rows at read time (adding latency to the list endpoint) or add a separate diff step at write time anyway — reducing one of the main advantages. But I'm not sure how important the "what changed" info really is, or if we simply want the ability to roll back easily, or "flip through" displaying prior versions for preview's sake. Foreign key constraints and referential integrity get more complex with append-only rows sharing IDs with other entities (e.g. charts pointing to datasets by datasource_id — which version of the dataset does that reference?). For pre-existing entities with no prior version row, you'd still need a synthetic baseline inserted on first save, same as the current proposal. Overall, the append-only approach seems most attractive _if_ the goal is minimizing schema complexity and avoiding the Continuum dependency, but it trades that simplicity for more invasive changes to the write path and loses the structured change records that the proposal considers load-bearing for the V2 UI. Worth discussing whether those tradeoffs make sense, especially given the Continuum friction already documented here. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
