René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Cascade may fail when Part table references another Part with renamed foreign keys","articleBody":"## Summary\n\n`Diagram.cascade()` with `part_integrity=\"cascade\"` may not correctly propagate restrictions when a Part table references another Part table instead of its Master directly, especially with renamed (projected) foreign keys.\n\n## Context\n\nDiscussion: #1232 (Spyglass Merge table pattern)\nRelated: #1423 (`Diagram.trace()` — same issue applies in the upstream direction)\n\n## Problem\n\nThe Part→Master upward propagation in `_propagate_restrictions()` (diagram.py lines 514-537) does two things:\n\n1. **Identifies the Master** via `extract_master(target)` — uses the `__` naming convention to derive the master table name from the part table name\n2. **Restricts the Master** via `master_ft.proj() \u0026 child_ft.proj()` — joins on shared primary key attributes\n\nThis assumes the Part table shares primary key attributes directly with its Master.\n\n### Case 1: Part references another Part with renamed FK (no direct Master reference)\n\n```python\n@schema\nclass Master(dj.Manual):\n    definition = \"\"\"\n    master_id : smallint\n    \"\"\"\n\n    class PartA(dj.Part):\n        definition = \"\"\"\n        -\u003e master\n        part_a_id : smallint\n        \"\"\"\n\n    class PartB(dj.Part):\n        definition = \"\"\"\n        -\u003e Master.PartA.proj(src_master='master_id', src_part='part_a_id')\n        part_b_id : smallint\n        \"\"\"\n```\n\nPartB has no direct FK to Master — it references PartA with renamed keys (`src_master` ← `master_id`, `src_part` ← `part_a_id`). When cascade reaches PartB:\n- `extract_master` correctly identifies Master by naming convention\n- But `master_ft.proj() \u0026 child_ft.proj()` joins on shared attribute names — `master_id` is not in PartB (it was renamed to `src_master`), so the join finds no common attributes\n- The intermediate PartA restriction is also skipped\n\n### Case 2: Part references another Part only (no Master reference at all)\n\n```python\n@schema\nclass Master(dj.Manual):\n    definition = \"\"\"\n    master_id : smallint\n    \"\"\"\n\n    class PartA(dj.Part):\n        definition = \"\"\"\n        -\u003e master\n        part_a_id : smallint\n        \"\"\"\n\n    class PartB(dj.Part):\n        definition = \"\"\"\n        -\u003e Master.PartA\n        part_b_id : smallint\n        \"\"\"\n```\n\nPartB references PartA directly (inheriting `master_id` and `part_a_id`). The restriction path should be PartB → PartA → Master. The current code jumps from PartB to Master via `proj() \u0026 proj()`. If `master_id` is inherited through PartA, the join may work by coincidence — but PartA's restriction is skipped entirely.\n\n### Case 3: Merge table with renamed reference from a table with different PK\n\n```python\n@schema\nclass Merge(dj.Manual):\n    definition = \"\"\"\n    merge_id : uuid\n    \"\"\"\n\n    class Source1(dj.Part):\n        definition = \"\"\"\n        -\u003e master\n        ---\n        -\u003e UpstreamPipeline1\n        \"\"\"\n\n    class Source2(dj.Part):\n        definition = \"\"\"\n        -\u003e master\n        ---\n        -\u003e UpstreamPipeline2\n        \"\"\"\n\n@schema\nclass Downstream(dj.Computed):\n    definition = \"\"\"\n    downstream_id : smallint\n    ---\n    -\u003e Merge\n    -\u003e Merge.proj(comparison_src='merge_id')\n    \"\"\"\n```\n\nDownstream has its own primary key and two FKs into Merge — one direct, one renamed via `.proj()`. Cascade from Downstream needs to reach Merge's Parts through both FK paths. The Part→Master propagation doesn't account for the renamed FK (`comparison_src` → `merge_id`).\n\n## Expected behavior\n\nCascade should correctly propagate restrictions through Part→Part→Master chains, including cases with renamed foreign keys (via `.proj()`), by following the actual FK path rather than relying on shared attribute names.\n\n## Proposed fix\n\nWhen propagating from a Part to its Master:\n1. If the Part doesn't share PK attributes directly with Master, follow the FK chain through intermediate Part tables\n2. Apply the standard restriction propagation rules (including `attr_map` alias handling from `_apply_propagation_rule`) at each step, rather than a direct `proj() \u0026 proj()` join\n\n## Verification\n\nNeeds test cases covering:\n- PartB references PartA with renamed FK (no direct Master reference) — verify Master is correctly restricted\n- PartB references PartA directly (no Master reference) — verify PartA and Master are both restricted\n- Renamed FK back to same Master via `.proj()` from a table with different PK — verify both paths are traced","author":{"url":"https://github.com/dimitri-yatsenko","@type":"Person","name":"dimitri-yatsenko"},"datePublished":"2026-04-06T20:21:51.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":1},"url":"https://github.com/1429/datajoint-python/issues/1429"}