SEPURI-SAI-KRISHNA commented on code in PR #45301:
URL: https://github.com/apache/superset/pull/45301#discussion_r4278409013
##########
superset/commands/dashboard/importers/v1/utils.py:
##########
@@ -183,6 +186,23 @@ def update_id_refs( # pylint: disable=too-many-locals #
noqa: C901
return fixed
+def _remap_legacy_chart_id(old_id: Any, id_map: dict[int, int]) -> int | None:
+ """Map one legacy integer chart ID to its new ID, or ``None``.
+
+ The integer-keyed metadata fields can hold a string rather than an int, and
+ can name a chart that is not in the bundle: nothing prunes them when a
+ chart is deleted or leaves a dashboard, and a chart in the layout is
+ skipped at import when its dataset is unresolvable. Returning ``None`` lets
+ the caller drop an unresolvable reference rather than fail the whole
+ import. The exporter coerces the same fields the same way; see
+ ``superset.commands.dashboard.export._stabilize_chart_ids``.
+ """
+ try:
+ return id_map.get(int(old_id))
Review Comment:
Leaving this one as it is, deliberately.
`True` is unchanged by this PR. `True == 1` as a dict key, so master's
`id_map[old_id]` already resolves it against chart 1 wherever the map holds 1,
and `int(True)` does the same thing.
`101.7` is the only real difference: master raises and fails the whole
import, this maps it to 101. Neither answer is right for a chart ID that is
already nonsense, and the export side does the identical bare `int()` in
`_stabilize_chart_ids.remap_id`, which is what keeps the two directions
agreeing on these fields. Tightening only the importer would put them out of
step on the same metadata. If float chart IDs are worth rejecting outright,
both sides should reject them, and that is a separate change from stopping the
opaque import failure.
--
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]
