exwiw 1.1.3 → 1.1.4

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 0feed4cda7c72c24738b7ccc03fa5cadc5321b636e48a86e07d8a169c5b7d941
-  data.tar.gz: 50241d3f38a64485adcfbc8740e5558e8049c136762068f56e9b505a93251d19
+  metadata.gz: edfbfddf23cb6df92da93914c6ee111a1ca7fc0085f096e82b894c8a4573b398
+  data.tar.gz: 8a96062ee9e37c1a12daec122420c1e91a06194c5f1ba1aadc3a5a5bc303a534
 SHA512:
-  metadata.gz: 1fad77e8f61f216afc2c9af89f54784e90fc50bfa691b29bd198727be29a6114d208d867e261c89e6b14d3ad27d385c6e981bd133df4803d2cab4c201eb9e090
-  data.tar.gz: a874e74e0c5c6fe674511de041baf80b80c7dc6495b7c96a950d5200f393a9e6e6dfa004f0d341245fdf576e4f42c0425079225895e9143f8001612a6d403383
+  metadata.gz: f16c16b056138f857fcc54b1015eea30969989bb6604e5ea7fd99e2e0ab43d649a80dffc2e1887939f934ec951da28a53981a1debca854ad2bf006cf2f4cfaf3
+  data.tar.gz: e4e119962a0bc285f03e18e9540c5d7efd98b7d758240ab81f0274ee5cd44105dfeb0b15302734f5586f4e7ac4ad7933c331343090e0445aaee32c22c5e2459f

data/CHANGELOG.md

@@ -2,6 +2,12 @@
 
 ## [Unreleased]
 
+## [1.1.4] - 2026-09-18
+
+### Fixed
+
+- **Polymorphic arms are grouped by the type column, so a config that gives each arm its own foreign key no longer loses rows.** The multi-arm walk keyed the group on `(foreign_key, foreign_type)`, which fits what the generators emit for Rails (`<name>_id` + `<name>_type`) but not a hand-written config where one type column selects between several foreign key columns — `merchant_application_type` choosing between `merchant_application_id` and `external_application_id`, say. Such arms were not recognised as siblings, so the table fell back to the single-path behavior: only the arm the BFS happened to settle on was extracted and every other arm's rows were dropped without a warning. Which arm survived depended on path length, so a table could even lose the arm it used to keep once a shorter one appeared. The group is now keyed on `foreign_type` alone and each arm joins on its own foreign key; two *independent* polymorphic associations have distinct type columns and stay in distinct groups, as before. Two consequences for such a table, both already true of the single-foreign-key case: its SQL becomes the `UNION` id-set form instead of a single JOIN, and `batch_scope` on it is now rejected in pre-flight (a batch of one terminus's ids does not constrain the other arms).
+
 ## [1.1.3] - 2026-09-08
 
 ### Fixed

data/README.md

@@ -811,6 +811,7 @@ Notes:
 - **Only arms that reach the scope are included.** An arm whose target has no scope of its own is dropped, never widened — an unscoped arm would pull in every tenant's rows. An arm marked `"ignore": true` is dropped as usual, before any of this.
 - An arm's target does not need a `belongs_to` path to a scoped table: if it is scoped by other means (referenced-by, [`reverse_scope`](#reverse-scope-for-multi-referencer-tables-reverse_scope), or the parent cascade) the arm probes that query's ids instead, still pinned by the type column.
 - An arm whose target is scoped **through this same table** (e.g. `active_storage_blobs`, narrowed by referenced-by from `active_storage_attachments`, appearing as an `ActiveStorage::Blob` arm of those same attachments) is dropped: adopting it would make the two tables scope each other and leave the referenced table short of rows the join table kept — a dangling foreign key on import.
+- **Arms are grouped by the type column (`foreign_type`), not by the foreign key.** Rails keeps every arm's id in one `<name>_id` column, which is what the generators emit, but a hand-written config may give each arm its own foreign key while one type column still selects between them — e.g. `merchant_application_type` choosing between `merchant_application_id` and `external_application_id`. Those are arms of the same discriminator, so each is resolved and joined on its own key. Two *independent* polymorphic associations on one table have distinct type columns and therefore stay in distinct groups.
 - Nothing changes when there is a single arm, or when the walk leaves through a non-polymorphic `belongs_to`: the plain single-JOIN SQL is emitted, byte for byte as before.
 - This applies to the scope-column mode walk. The single `--target-table` mode still follows one path per table.
 

data/lib/exwiw/query_ast_builder.rb

@@ -880,7 +880,7 @@ module Exwiw
     # single shortest path `find_path_to_scoped` returns is the whole story and
     # this returns one arm — the historical behavior, byte-for-byte.
     #
-    # A *polymorphic* hop is different: one (foreign_key, foreign_type) pair
+    # A *polymorphic* hop is different: one type column (`foreign_type`)
     # addresses several parent tables — one per `type_value` — and each row
     # belongs to whichever arm its type column names. Following a single path
     # therefore extracts only the rows of that one arm and silently drops every
@@ -888,7 +888,7 @@ module Exwiw
     # settles on one owner table and the query filters `record_type = '<that
     # one>'`, so attachments of the other 20-odd owner types never make it into
     # the dump.) So when the shortest path leaves through a polymorphic relation,
-    # resolve every sibling arm of the same (foreign_key, foreign_type) group.
+    # resolve every sibling arm sharing its type column.
     #
     # Note the entry condition: this only ever widens a table that *already*
     # reaches the scope through a polymorphic join path. A table with no path at
@@ -967,11 +967,19 @@ module Exwiw
       ScopedArm.new(relation: relation, target_query: target_query)
     end
 
-    # The polymorphic belongs_to arms sharing the (foreign_key, foreign_type) of
-    # the relation this table uses to reach `first_hop_table_name`, or nil when
-    # the caller should stay on the single-path behavior: the hop is not
-    # polymorphic, or its group has only one arm, or this table has no usable
-    # primary key to union the arms on.
+    # The polymorphic belongs_to arms sharing the `foreign_type` of the relation
+    # this table uses to reach `first_hop_table_name`, or nil when the caller
+    # should stay on the single-path behavior: the hop is not polymorphic, or its
+    # group has only one arm, or this table has no usable primary key to union
+    # the arms on.
+    #
+    # The group is keyed on the type column alone. A Rails association stores
+    # every arm's id in one column, but a hand-written config may give each arm
+    # its own foreign key while one type column still selects between them; both
+    # are arms of the same discriminator, and everything downstream reads
+    # `foreign_key` off the arm's own relation. Two *independent* polymorphic
+    # associations on one table have distinct type columns, so they stay in
+    # distinct groups.
     #
     # The relation is looked up with `belongs_to(table_name)` — the same lookup
     # #build_scoped_join_clause performs — so the decision is made about exactly
@@ -983,9 +991,7 @@ module Exwiw
       return nil if relation.nil? || !relation.polymorphic?
 
       arms = table.belongs_tos.select do |other|
-        other.polymorphic? &&
-          other.foreign_key == relation.foreign_key &&
-          other.foreign_type == relation.foreign_type
+        other.polymorphic? && other.foreign_type == relation.foreign_type
       end
       arms.size > 1 ? arms : nil
     end

data/lib/exwiw/version.rb

@@ -1,5 +1,5 @@
 # frozen_string_literal: true
 
 module Exwiw
-  VERSION = "1.1.3"
+  VERSION = "1.1.4"
 end

metadata

@@ -1,7 +1,7 @@
 --- !ruby/object:Gem::Specification
 name: exwiw
 version: !ruby/object:Gem::Version
-  version: 1.1.3
+  version: 1.1.4
 platform: ruby
 authors:
 - Shia