-
Notifications
You must be signed in to change notification settings - Fork 21.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Accidentally using :class instead of :class_name in association gives misleading error #19659
Comments
Right, I agree it might be easy for someone use |
Renaming seems fine. |
|
+1 on (someone who made this typo as well) |
Why nobody don't think about giving meaningful error message instead of renaming the option name. class is really fit for this option name. |
@meinac the point is that this option is for internal use only, not for people to consume, and we'd have no way to differentiate when it's being used by the framework or by a developer on its own code (that's why they should not - consider this as private, an implementation detail). |
In 1f006c an option was added called :class to allow passing anonymous classes to association definitions. Since using :class instead of :class_name is a fairly common typo even amongst experienced developers this can result in hard to debug errors arising in raise_on_type_mismatch? To fix this we're renaming the option from :class to :anonymous_class as that is a more correct description of what the option is for. Since this was an internal, undocumented option there is no need for a deprecation. Fixes #19659 (cherry picked from commit ac2b7a5) Conflicts: activerecord/CHANGELOG.md activerecord/lib/active_record/associations/builder/association.rb
I'm not a Rails core dev obviously, but I'm just hoping in to tell you that I simply opted for using the BTW, something like |
That is by design; no-one is supposed to use this internal option. |
If you define an association using a custom class and then make the all-too common typo of using
:class
instead of:class_name
then the change made in 1f006cd will give rise to a hard to track down error inraise_on_type_mismatch!
becauseis_a?
is called with a string instead of a class.Since
:class
option is private and added for supporting HABTM associations on top of HMT then there is a question whether we should change the option name to be something else less prone to error or try to detect the error when building the association.wdyt? @tenderlove @sgrif @rafaelfranca @carlosantoniodasilva
The text was updated successfully, but these errors were encountered: