ActiveRecord::AssociationTypeMismatch with same class name -- added helpful exception message
Reported by Arya Asemanfar | May 14th, 2008 @ 12:10 AM
ActiveRecord raises an exception when the expected class for an association differs from the class of object trying to be assigned.
Example:
@post.comments << "This is a string"
This works as expected and says raises an exception with "Comment expected, got String".
But sometimes, this can happen:
@comment.user = current_user
and an "User expected, got User" exception is raised. Which at first glance doesn't make sense. What happened here is the Comment model is in a plug-in and since the Comment model already got loaded and isn't re-loaded every request in development (since it's in a plugin), the User class the Comment association is expecting differs from the User class that is in the current runtime.
Anyway, I wrote a patch to inform the user that the class was changed and that they should try restarting mongrel.
Patch attached.
Comments and changes to this ticket
-
Arya Asemanfar May 14th, 2008 @ 12:12 AM
I'm not sure if this is required or not, but here is my commit on my fork of Rails on GitHub:
-
Arya Asemanfar May 14th, 2008 @ 02:13 AM
Sorry about that. I didn't know I wasn't supposed to fork Rails unless it's some big change. I deleted my fork.
-
Pratik May 14th, 2008 @ 08:55 AM
- → State changed from “new” to “invalid”
I think this should be in a plugin like http://groups.google.com/group/r...
Thanks!
-
Arya Asemanfar May 14th, 2008 @ 04:30 PM
Hi Pratik,
If the suggestion-type language is too superfluous for a Rails error message, may I suggest two alternatives that avoids the Windows-esque type error message of "User expected, got User":
1. What do you think about adjusting changing the error message to something like "older version of User expected, received a newer version of User" if the two class names are textually identical? I'm not sure about the word 'version' in that sentence, but something to indicate to the developer that they simply received the error because there are 2 definitions of the class, and we were expecting an older one.
2. This one is a little more active in solving the problem, although I'm not sure if it's a valid solution. What if instead of comparing @reflection.klass and record.class, it compared the string representations of them? So it wouldn't raise an exception when it receives User and expected and older version of User. Are there any cases where it's unsafe to assume that it's the same class but just an older version?
Anyway, please let me know what you think. I'm just trying to help some people save time considering the "User expected, got User" error message is unclear.
-
Jeremy McAnally May 14th, 2008 @ 09:35 PM
I'm not sure why it's just showing the class name rather than something like "expected User (), got User (#343e4>)." It'd be trivial to add a call to #inspect and would fix the biggest problem with this error message.
Ideally it'd be nice to show the class's ancestors or something too but maybe that's too verbose.
-
Star Trader May 14th, 2008 @ 10:29 PM
+1
This is a needed clarification of an otherwise nonsense error message. It installs properly and works as advertised. I found no bugs or performance issues, and all tests still pass.
Active record's extensive framework make hand debugging difficult. I believe that it has been, and should continue to be the policy of the maintainers to provide clear and helpful error messages by default. I respectfully disagree with Pratik that this type od developer assistance should not come with the default package.
I request that this ticket be reopened and that once sufficient testing has been don that it be merged into Edge Rail. While I find no reason not to also include it in the 2.1 release, it is non-critical.
-
rick May 15th, 2008 @ 07:23 PM
- → State changed from “invalid” to “open”
I don't like the error message itself. I'd personally go with Jeremy's suggestion of showing the object_ids of the two differing classes, with a note in the has_many docs explaining why this happens.
Also, you should look into making your plugins reloadable. Though, that should really be documented so folks know the option is available (and honestly has been since Rails 1.1.x).
-
-
Repository May 21st, 2008 @ 10:50 AM
- → State changed from “open” to “resolved”
(from [19d7b1d22bd68af00244ddc3e1f35cec187e9120]) Verbose ActiveRecord::AssociationTypeMismatch exception message. [#189 state:resolved]
-
Lawrence Pit October 2nd, 2008 @ 04:58 AM
- → Tag changed from “” to “activerecord enhancement”
See #229 if you still experience issues with this.
Please Login or create a free account to add a new comment.
You can update this ticket by sending an email to from your email client. (help)
Create your profile
Help contribute to this project by taking a few moments to create your personal profile. Create your profile »
Source available from github
The Git repository resides at http://github.com/rails
Check out the current development trunk (Edge Rails) with:
git clone git://github.com/rails/rails.git
Creating or reviewing a patch
See the contributor guide.
Creating a feature request
Please don't. If you want a new feature in Rails, you'll have to pull up your sleeves and get busy yourself. Or convince someone else to do it. See the contributor guide on how to get going. But posting them here is just going to lead to ticket root.
Creating a bug report
When creating a bug report, be sure to include as much relevant information as possible. Post the code sample that causes the problem. Preferably, alter the unit tests and show through either changed or added tests how the expected behavior is not occuring.
Security vulnerabilities should be reported via an email to security@rubyonrails.org, do not use trac for reporting security vulnerabilities. All content in trac is publicly available as soon as it is posted.
Then don't get your hopes up. Unless you have a "Code Red, Mission Critical, The World is Coming to an End" kinda bug, you're creating this ticket in the hope that others with the same problem will be able to collaborate with you on solving it. Do not expect that the ticket automatically will see any activity or that others will jump to fix it. Creating a ticket like this is mostly to help yourself start on the path of fixing the problem and for others to sign on to with a "I'm having this problem too".
Josh Bassett