|
979 | 979 | allowing instances of one model (Physician) to be associated with multiple
|
980 | 980 | instances of another model (Patient) through a third "join" model (Appointment).
|
981 | 981 |
|
| 982 | +We call `Physician.appointments` and `Appointment.patient` the _through_ and |
| 983 | +_source_ associations of `Physician.patients`, respectively. |
| 984 | + |
982 | 985 | 
|
984 | 987 |
|
@@ -1013,7 +1016,8 @@ created with `physician_id` and `patient_id` columns, establishing the
|
1013 | 1016 | many-to-many relationship between `physicians` and `patients`.
|
1014 | 1017 |
|
1015 | 1018 | INFO: The through association can be any type of association, including other
|
1016 |
| -through associations, but it cannot be a polymorphic association. |
| 1019 | +through associations, but it cannot be [polymorphic](#polymorphic-associations). |
| 1020 | +Source associations can be polymorphic as long as you provide a source type. |
1017 | 1021 |
|
1018 | 1022 | You could also consider using a [composite primary
|
1019 | 1023 | key](active_record_composite_primary_keys.html) for the join table in the
|
@@ -1125,6 +1129,9 @@ end
|
1125 | 1129 | This setup allows a `supplier` to directly access its `account_history` through
|
1126 | 1130 | its `account`.
|
1127 | 1131 |
|
| 1132 | +We call `Supplier.account` and `Account.account_history` the _through_ and |
| 1133 | +_source_ associations of `Supplier.account_history`, respectively. |
| 1134 | + |
1128 | 1135 | 
|
1130 | 1137 |
|
@@ -1154,7 +1161,8 @@ end
|
1154 | 1161 | ```
|
1155 | 1162 |
|
1156 | 1163 | INFO: The through association can be any type of association, including other
|
1157 |
| -through associations, but it cannot be a polymorphic association. |
| 1164 | +through associations, but it cannot be [polymorphic](#polymorphic-associations). |
| 1165 | +Source associations can be polymorphic as long as you provide a source type. |
1158 | 1166 |
|
1159 | 1167 | ### `has_and_belongs_to_many`
|
1160 | 1168 |
|
|
0 commit comments