mikebridge commented on issue #39492:
URL: https://github.com/apache/superset/issues/39492#issuecomment-4424299084
> Wanted to float one more alternative approach
@rusackas Interesting — I had not thought of this (even though it seems
similar to the soft-deletion SIP), but if I understand the concept correctly, I
think the biggest downside (as you note) is the foreign-key issue. In an
append-only model, every dependent entity's FK has to decide which version of
the target it points at, and the answer is complex either way: live (versioning
is then invisible from the dependent's side---I don't know what kind of
side-effects this would have but it sounds like a large change) or a specific
version (restore has to cascade FK rewrites). On top of that there are FAB
per-row permissions like "`can_read` on Slice 42", embedded-dashboard guest
tokens, and external integrations that bookmark ids — all of which assume a
stable PK. Worse for import/export: the existing pipeline already resolves int
IDs → UUIDs at export time (e.g. `position_json.chartId` → `chartUuid` and
`native_filter.targets[].datasetId` → `datasetUuid`), assuming `<ent
ity>.uuid` is on the live row. Under append-only that UUID is either per-row
(target system never saw it → import fails) or per-logical-entity (which is
what shadow tables already give us).
I think the same thing applies to the JSON-embedded pseudo-FKs you'd find in
`dashboard.json_metadata.default_filters`, `chart_configuration`, etc. — I
think every JSON walker (export, cross-filter scope, restore) would need
versioning-aware lookup to modify everything both on save and restore and
modify the references.
I think this gets more complex when we attach this to soft-deletions,
because a "deleted" record would become a different kind of "version" with (I
assume) its own set of store/restore rules for each entity, and we'd probably
have to integrate that into the storage logic. Right now it's just a separate
boolean state flag with logic of its own.
And in terms of dependencies from external entities on these fks, I would
think that anything that references entity ids (whether in forks, embedded
sdks, urls, etc.) would be affected, and they would be largely out of our
control....
--
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]
