gabotorresruiz commented on code in PR #45543:
URL: https://github.com/apache/superset/pull/45543#discussion_r4355049445
##########
superset/daos/dashboard.py:
##########
@@ -646,20 +678,23 @@ def set_dash_metadata( # noqa: C901
# documented restore-reattach contract) and writing
# ``uuid: None`` into its position slot via ``uuid_map`` below.
#
- # The bypass must be session-scoped and cover the ASSIGNMENT,
- # not just the resolution query: assigning to
+ # The bypass must also cover the ASSIGNMENT: assigning to
# ``dashboard.slices`` makes the unit of work diff the new
- # collection against the existing one, which it lazy-loads at
- # that moment. A filtered baseline load would exclude the
- # trashed member, so the diff would treat it as net-new and
- # INSERT a ``dashboard_slices`` row that still exists (soft
- # delete never removes junction rows) — an IntegrityError on
- # the composite primary key on every save of a dashboard
- # containing a trashed chart.
+ # collection against the existing one. A baseline missing the
+ # trashed member makes the diff treat it as net-new and INSERT a
+ # ``dashboard_slices`` row that still exists (soft delete never
+ # removes junction rows), an IntegrityError on the composite
+ # primary key on every save of a dashboard containing a trashed
+ # chart. Lazy-loading the baseline inside the bypass is not
+ # enough: a dashboard loaded through a query carries the
+ # visibility filter into its own lazy loads. Read the baseline
+ # from the association table instead and install it as the
+ # committed state.
with skip_visibility_filter(db.session, Slice):
current_slices = (
db.session.query(Slice).filter(Slice.id.in_(slice_ids)).all()
)
+ _install_membership_baseline(dashboard)
dashboard.slices = current_slices
Review Comment:
Confirmed closed, and good catch @rebenitez1802. I rebuilt your repro
independently (query-loaded dashboard, one live chart in the layout, one
archived chart only in `dashboard_slices`) and landed on your exact numbers:
members `{1, 2}` on the merge base, `{1}` on `c927483eb`, `{1, 2}` again on
`e30773a10`.
On the design question that was left open, this implements the first of your
two options. `kept_archived` is subtracted against `layout_ids`, so an archived
member survives however it came to be missing from the submitted layout,
including a user explicitly deleting its placeholder tile. I measured that
shape separately (stored layout carrying the archived slot, submitted layout
without it): `{1, 2}` here, `{1}` on `c927483eb`. That is the merge-base
behaviour and it matches `UPDATING.md`, "saving a dashboard does not sever a
trashed member".
Worth saying out loud because @fitzee's review on `c927483eb` describes the
opposite as intended ("a save that deliberately removes an archived chart's
tile deletes its `dashboard_slices` row ... That's the right semantics"), so I
would rather the three of us agree which one we are shipping than have it
settled by whoever reads the diff last. My own read is that the `UPDATING.md`
line decides it and this branch is right.
--
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]
