mikebridge commented on code in PR #42469: URL: https://github.com/apache/superset/pull/42469#discussion_r3673619539
########## superset/versioning/restore.py: ########## @@ -0,0 +1,254 @@ +# Licensed to the Apache Software Foundation (ASF) under one +# or more contributor license agreements. See the NOTICE file +# distributed with this work for additional information +# regarding copyright ownership. The ASF licenses this file +# to you under the Apache License, Version 2.0 (the +# "License"); you may not use this file except in compliance +# with the License. You may obtain a copy of the License at +# +# http://www.apache.org/licenses/LICENSE-2.0 +# +# Unless required by applicable law or agreed to in writing, +# software distributed under the License is distributed on an +# "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY +# KIND, either express or implied. See the License for the +# specific language governing permissions and limitations +# under the License. +"""Write-side: restore a versioned entity to an earlier state. + +Companion to :mod:`superset.versioning.queries`. The +``BaseRestoreVersionCommand`` in :mod:`superset.commands.version_restore` +is the only intended caller; the backward-compat ``VersionDAO`` façade +in :mod:`superset.daos.version` re-exports ``restore_version``. + +Restore semantics are strictly per-entity: a restore rewrites the target +entity's own fields (and, for datasets, its own columns/metrics — the +aggregate's internal parts), never the content of other entities. A +dashboard restore reattaches membership to charts that still exist; +charts that have been deleted since the snapshot stay deleted and are +reported as skipped rather than revived or dangling. +""" + +from __future__ import annotations + +import logging +from dataclasses import dataclass, field +from datetime import datetime +from typing import Any +from uuid import UUID + +from sqlalchemy_continuum import version_class + +from superset.extensions import db +from superset.versioning.baseline import OPERATION_DELETE +from superset.versioning.queries import find_active_by_uuid +from superset.versioning.utils import single_flush_scope + +logger = logging.getLogger(__name__) + +# A DELETE version row (``OPERATION_DELETE``) is never a valid restore +# target: Continuum's ``Reverter`` would delete the live entity and report +# success — the opposite of the non-destructive contract — so the engine +# treats it as not-found. + + +# Per-model relationships that Continuum's Reverter recurses into during a +# restore — deliberately limited to the entity's OWN aggregate parts +# (``TableColumn`` / ``SqlMetric`` on ``SqlaTable``). ``Dashboard`` is NOT +# given ``slices`` here: recursing into the M2M would run a full child +# revert on every member chart, overwriting live charts' content with +# historical values (charts are shared entities with their own restore), +# and re-creating hard-deleted charts. Dashboard membership is instead +# reconstructed by :func:`_restore_dashboard_membership`. +# +# Unknown models fail closed (``LookupError``) rather than defaulting to a +# relation-less restore — a silently partial restore is worse than a loud +# failure (mirrors ``_RAISE_FOR_ACCESS_KWARG`` in ``api_helpers``). +_RESTORE_RELATIONS: dict[str, list[str]] = { + "SqlaTable": ["columns", "metrics"], + "Dashboard": [], + "Slice": [], +} + + +@dataclass +class RestoreResult: + """Outcome of a successful restore. + + ``skipped_slice_ids`` is only ever populated for dashboard restores: + member charts referenced by the snapshot that no longer exist and were + therefore not reattached (they stay deleted — restore never revives + entities). + """ + + entity: Any + skipped_slice_ids: list[int] = field(default_factory=list) + + +def restore_version( + model_cls: type, + entity_uuid: UUID, + transaction_id: int, + *, + entity: Any | None = None, +) -> RestoreResult | None: Review Comment: Good catch — taken in `c65d09f94e`, option (a). There is no live bug: `restore_version` has exactly one caller (`superset/commands/version_restore.py`), and its `validate()` loads the entity via `find_active_by_uuid(self.model_cls, self._uuid)` and then passes that same `self._uuid` through, so the two cannot currently disagree. But the reasoning holds for the next caller, and the failure mode you describe is the nasty kind — restoring one row while the audit trail names another. The engine now raises if they disagree rather than guessing, with a unit test pinning it. ########## superset/versioning/restore.py: ########## @@ -0,0 +1,254 @@ +# Licensed to the Apache Software Foundation (ASF) under one +# or more contributor license agreements. See the NOTICE file +# distributed with this work for additional information +# regarding copyright ownership. The ASF licenses this file +# to you under the Apache License, Version 2.0 (the +# "License"); you may not use this file except in compliance +# with the License. You may obtain a copy of the License at +# +# http://www.apache.org/licenses/LICENSE-2.0 +# +# Unless required by applicable law or agreed to in writing, +# software distributed under the License is distributed on an +# "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY +# KIND, either express or implied. See the License for the +# specific language governing permissions and limitations +# under the License. +"""Write-side: restore a versioned entity to an earlier state. + +Companion to :mod:`superset.versioning.queries`. The +``BaseRestoreVersionCommand`` in :mod:`superset.commands.version_restore` +is the only intended caller; the backward-compat ``VersionDAO`` façade +in :mod:`superset.daos.version` re-exports ``restore_version``. + +Restore semantics are strictly per-entity: a restore rewrites the target +entity's own fields (and, for datasets, its own columns/metrics — the +aggregate's internal parts), never the content of other entities. A +dashboard restore reattaches membership to charts that still exist; +charts that have been deleted since the snapshot stay deleted and are +reported as skipped rather than revived or dangling. +""" + +from __future__ import annotations + +import logging +from dataclasses import dataclass, field +from datetime import datetime +from typing import Any +from uuid import UUID + +from sqlalchemy_continuum import version_class + +from superset.extensions import db +from superset.versioning.baseline import OPERATION_DELETE +from superset.versioning.queries import find_active_by_uuid +from superset.versioning.utils import single_flush_scope + +logger = logging.getLogger(__name__) + +# A DELETE version row (``OPERATION_DELETE``) is never a valid restore +# target: Continuum's ``Reverter`` would delete the live entity and report +# success — the opposite of the non-destructive contract — so the engine +# treats it as not-found. + + +# Per-model relationships that Continuum's Reverter recurses into during a +# restore — deliberately limited to the entity's OWN aggregate parts +# (``TableColumn`` / ``SqlMetric`` on ``SqlaTable``). ``Dashboard`` is NOT +# given ``slices`` here: recursing into the M2M would run a full child +# revert on every member chart, overwriting live charts' content with +# historical values (charts are shared entities with their own restore), +# and re-creating hard-deleted charts. Dashboard membership is instead +# reconstructed by :func:`_restore_dashboard_membership`. +# +# Unknown models fail closed (``LookupError``) rather than defaulting to a +# relation-less restore — a silently partial restore is worse than a loud +# failure (mirrors ``_RAISE_FOR_ACCESS_KWARG`` in ``api_helpers``). +_RESTORE_RELATIONS: dict[str, list[str]] = { + "SqlaTable": ["columns", "metrics"], + "Dashboard": [], + "Slice": [], +} + + +@dataclass +class RestoreResult: + """Outcome of a successful restore. + + ``skipped_slice_ids`` is only ever populated for dashboard restores: + member charts referenced by the snapshot that no longer exist and were + therefore not reattached (they stay deleted — restore never revives + entities). + """ + + entity: Any + skipped_slice_ids: list[int] = field(default_factory=list) + + +def restore_version( + model_cls: type, + entity_uuid: UUID, + transaction_id: int, + *, + entity: Any | None = None, +) -> RestoreResult | None: + """Restore the entity identified by *entity_uuid* to the state captured + at *transaction_id* (the stable identifier resolved from a + ``version_uuid`` by :func:`superset.versioning.queries.resolve_version`). + + Returns a :class:`RestoreResult` wrapping the live entity, or ``None`` + when the UUID does not match an active entity, no version row exists at + *transaction_id*, or the target row is a DELETE — callers should + translate all three to a 404. + + Pass *entity* to skip the ``find_active_by_uuid`` lookup when the + caller has already loaded the row (the command's ``validate()`` has). + + Uses SQLAlchemy-Continuum's native ``version_obj.revert(relations=...)`` + and delegates commit to the caller (expected to be a command decorated + with ``@transaction()``). The ``relations`` list depends on the model + type and is looked up in :data:`_RESTORE_RELATIONS`; unknown models + raise ``LookupError`` rather than silently restoring without children. + + Within the same flush, ``changed_on`` / ``changed_by_fk`` are + re-stamped with the current time and the restoring user's id so the + new version row produced by the restoring commit reflects who clicked + Restore, not the original author. ``created_on`` / ``created_by_fk`` + are left alone. + """ + if entity is None: + entity = find_active_by_uuid(model_cls, entity_uuid) + if entity is None: + return None Review Comment: Good catch — taken in `c65d09f94e`, option (a). There is no live bug: `restore_version` has exactly one caller (`superset/commands/version_restore.py`), and its `validate()` loads the entity via `find_active_by_uuid(self.model_cls, self._uuid)` and then passes that same `self._uuid` through, so the two cannot currently disagree. But the reasoning holds for the next caller, and the failure mode you describe is the nasty kind — restoring one row while the audit trail names another. The engine now raises if they disagree rather than guessing, with a unit test pinning it. ########## superset/versioning/api_helpers.py: ########## @@ -264,3 +275,56 @@ def get_version_endpoint( entity_uuid, entity_id=entity.id, ) + + +def restore_version_endpoint( + api: Any, + model_cls: type[Model], + command_cls: type[Any], + uuid_str: str, + version_uuid_str: str, +) -> Response: + """Body of ``POST /api/v1/{resource}/<uuid>/versions/<version_uuid>/restore``. + + *command_cls* is the entity's ``BaseRestoreVersionCommand`` subclass; + its ``not_found_exc`` / ``forbidden_exc`` / ``failed_exc`` ClassVars + drive the exception→HTTP mapping, so this body stays generic. + Authorization and the ``ENABLE_VERSIONING_CAPTURE`` kill-switch gate + live in the command's ``validate()`` — with capture off the route is + inert (404) because a revert without Continuum's write listeners + would be a destructive, untracked write. + """ + try: + entity_uuid = UUID(uuid_str) + except ValueError: + return api.response_400(message="Invalid UUID") + try: + version_uuid = UUID(version_uuid_str) + except ValueError: + return api.response_400(message="Invalid version UUID") + + try: + result = command_cls(entity_uuid, version_uuid).run() + except command_cls.not_found_exc: + return api.response_404() + except command_cls.forbidden_exc: + return api.response_403() + except command_cls.failed_exc as ex: + logger.error("Error restoring %s version: %s", model_cls.__name__, ex) + return api.response_422(message=str(ex)) Review Comment: Taken in `c65d09f94e` — switched to `logger.exception(...)` and dropped `ex` from the args, keeping the 422 response unchanged. The message string already carries the model name, and `str(ex)` still reaches the client, so the only change is that the traceback now survives into the logs. -- 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]
