You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: ruby/hyper-model/polymorph-notes.md
+20-2Lines changed: 20 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -12,8 +12,8 @@ class Product < ApplicationRecord
12
12
end
13
13
```
14
14
15
-
product/employee.pictures -> works almost as normal has_many as far as Hyperstack client is concerned
16
-
imageable is the "alias" of product/employee. Its as if there is a class Imageable that is the superclass
15
+
product|employee.pictures -> works almost as normal has_many as far as Hyperstack client is concerned
16
+
imageable is the "alias" of product|employee. Its as if there is a class Imageable that is the superclass
17
17
of Product and Employee.
18
18
19
19
so has_many :pictures means the usual thing (i.e. there is a belongs_to relationship on Picture) its just that
@@ -89,3 +89,21 @@ end
89
89
its all about the collection inverse. The inverse class of the has_many is the class containing the polymorphic belongs to. But the inverse of a polymorphic belongs to depends on the value. If the value is nil or a DummyPolyClass object then there is no inverse.
90
90
91
91
I think if inverse takes this into account then `<<` and `=` should just "work" (well almost) and probably everything else will to.
92
+
93
+
### NOTES on the DummyPolyClass...
94
+
95
+
it needs to respond to reflect_on_all_associations, but just return an empty array. This way when we search for matching inverse attribute we won't find it.
96
+
97
+
### Status
98
+
99
+
added model to inverse, inverse_of, find_inverse
100
+
101
+
if the relationship is a collection then we will always know the inverse.
102
+
103
+
The only time we might no know the inverse is if its NOT a collection (i.e. belongs_to)
104
+
105
+
So only places that are applying inverse to an association that is NOT a collection do we have to pass the model in.
106
+
107
+
All inverse_of method calls have been checked and updated
108
+
109
+
that leaves inverse which is only used in SETTERS hurray!
0 commit comments