Browse files

Rewrites a CHANGELOG entry.

The entry is basically copy & paste of the commit message, but the CHANGELOG
has a different purpose than Git history, it just communicates what is new:

* No need to explain why did the bug happen (unless it is truly relevant).

* No need to explain how was the bug fixed.

* Whether the user gives new names to columns does not really matter, use of
  select to cherry-pick a column for example also presented that behaviour.
  Non-selected attributes are the key, either because they were not included
  in the selected list, or because they were but with a different alias.

* In the case of an attribute alias, what you really want to depict is that
  respond_to? returns false for the original attribute name.
  • Loading branch information...
1 parent 7004f10 commit d32ef7c7a5a1e29f64eb3c2240c642c7b0c73f25 @fxn fxn committed Apr 20, 2013
Showing with 6 additions and 16 deletions.
  1. +6 −16 activerecord/
@@ -1,23 +1,13 @@
## Rails 4.0.0 (unreleased) ##
-* If a query selects only a few columns and gives custom names to
- those columns then `respond_to?` was returning true for the non
- selected columns. However calling those non selected columns
- raises exception.
+* If a model was instantiated from the database using `select`, `respond_to?`
+ returns false for non-selected attributes. For example:
- post ="'title' as post_title").first
+ post =
+ post.respond_to?(:body) # => false
- In the above case when `post.body` is invoked then an exception is
- raised since `body` attribute is not selected. However `respond_to?`
- did not behave correctly.
- post.respond_to?(:body) #=> true
- Reason was that Active Record calls `super` to pass the call to
- Active Model and all the columns are defined on Active Model.
- Fix is to actually check if the data returned from the db contains
- the data for column in question.
+ post ='title as post_title').first
+ post.respond_to?(:title) # => false
Fixes #4208.

0 comments on commit d32ef7c

Please sign in to comment.