Add support for the rails 5.2 polymorphic name method#31
Conversation
doliveirakn
force-pushed
the
polymorphic-names-support
branch
3 times, most recently
from
6f53b59 to
1d8f3ec
Compare
doliveirakn
force-pushed
the
polymorphic-names-support
branch
from
1d8f3ec to
c1f717a
Compare
|
This doesn't seem to be the case anymore in favor just checking that it responds to polymorphic_name instead now? |
|
@Drew-Goddyn that was the case the first attempt at support but is no longer the case. I'll remove that from the description. |
| define_method "#{name}=" do |record| | ||
| super(record) | ||
| send("#{foreign_type}=", record.class) | ||
| association(name).loaded! |
There was a problem hiding this comment.
What's the reason behind this change?
There was a problem hiding this comment.
if we write the association in the super(record) and then change then *_type column, it will mark the association as stale, and lose the reference of it (causing it to want to lookup the object again).
By marking the assocaition as loaded afterwards, we guarantee that if once you write the record, it maintains that association.
3 participants
What problem does this solve
Prior to Rails 5.2, there wasn't a great consensus on what to use for the polymorphic_name of a class. In some instance it was the class name, in other instances, it seemed like it was the name that was used for single table inheritance.
As of Rails 5.2, there is now a canonical way which is to call
polymorphic_nameon the class. Now that there is a canonical way, we should remove the redundant lookupsHow does this solve it
We don't want to completely break support, so this will check if a class responds to
polymorphic_nameand if so, it'll use that. It'll keep all of the other fallbacks in place though.