| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| |
|
|
|
|
|
|
| |
Object#respond_to? returns singletons and thus we inherit that contract.
The implementation of the predicate is good, but the test is only
checking boolean semantics, which in this case is not enough.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
fixes #4208
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.
post = Post.select("'title' as post_title").first
In the above case when `post.body` is invoked then an exception is
raised since `body` attribute is not selected. Howevere `respond_to?`
did not behave correctly.
pos.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.
|
| |
|
| |
|
| |
|
|
|
|
| |
We should not need any `serialized_attributes` checks outside `ActiveRecord::AttributeMethods::Serialization` module.
|
|\
| |
| |
| |
| |
| |
| | |
Conflicts:
actionpack/lib/action_controller/metal/mime_responds.rb
activerecord/lib/active_record/attribute_methods.rb
guides/source/working_with_javascript_in_rails.md
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This fixes the following behaviour:
class Person < ActiveRecord::Base
belongs_to :company
end
# Before:
person = Person.select('id').first
person[:name] # => nil
person.name # => ActiveModel::MissingAttributeError: missing_attribute: name
person[:company_id] # => nil
person.company # => nil
# After:
person = Person.select('id').first
person[:name] # => ActiveModel::MissingAttributeError: missing_attribute: name
person.name # => ActiveModel::MissingAttributeError: missing_attribute: name
person[:company_id] # => ActiveModel::MissingAttributeError: missing_attribute: company_id
person.company # => ActiveModel::MissingAttributeError: missing_attribute: company_id
Fixes #5433.
|
|/
|
|
|
|
|
|
|
|
| |
In the end I think the pain of implementing this seamlessly was not
worth the gain provided.
The intention was that it would allow plain ruby objects that might not
live in your main application to be subclassed and have persistence
mixed in. But I've decided that the benefit of doing that is not worth
the amount of complexity that the implementation introduced.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
When inserting new records, only the fields which have been changed
from the defaults will actually be included in the INSERT statement.
The other fields will be populated by the database.
This is more efficient, and also means that it will be safe to
remove database columns without getting subsequent errors in running
app processes (so long as the code in those processes doesn't
contain any references to the removed column).
|
| |
|
| |
|
| |
|
|
|
|
| |
ActiveRecord#attributes optimization: minimize objects created
|
| |
|
|\
| |
| | |
Refactoring of `arel_attributes_values` method
|
| | |
|
| | |
|
|/ |
|
| |
|
| |
|
|
|
|
|
|
| |
From 2c667f69aa2daac5ee6c29ca9679616e2a71532a.
Thanks @pwnall for the heads-up.
|
| |
|
|
|
|
| |
This reverts commit 21eadc1b3f2eb818a4833381ee0a6cfa205f2955.
|
|
|
|
|
| |
This is the 'top level' connection, inherited by any models that include
ActiveRecord::Model or inherit from ActiveRecord::Base.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
This is good because it reduces duplication.
|
| |
|
|
|
|
|
|
|
|
|
| |
There is no meaningful performance penalty in defining attribute
methods, since it only happens once.
There is also no reason *not* to define them, since they get thrown in
an included module, so they will not 'overwrite' anything. In fact, this
is desirable, since it allows us to call super.
|
|
|
|
| |
We can just use method_defined? and private_method_defined?
|
|
|
|
|
|
| |
This shouldn't ever happen unless people are doing something
particularly weird, but adding a deprecation in case there are bugs not
caught by our tests.
|
|
|
|
|
|
| |
Check respond_to_without_attributes? in method_missing. If there is any
method that responds (even private), let super handle it and raise
NoMethodError if necessary.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes a situation I encountered where a subclass would cache the
name of a generated attribute method in @_defined_class_methods. Then,
when the superclass has it's attribute methods undefined, the subclass
would always have to dispatch through method_missing, because the
presence of the attribute in @_defined_class_methods would mean that it
is never generated again, even if undefine_attribute_methods is called
on the subclass.
There various other confusing edge cases like this. STI classes share
columns, so let's just keep all the attribute method generation state
isolated to the base class.
|
|
|
|
| |
Make sure we don't redefine an already-defined attribute method.
|
| |
|
|
|
|
|
|
|
|
| |
ActiveRecord, so it's flexible now
[#6428 state:resolved]
Signed-off-by: José Valim <jose.valim@gmail.com>
|
|
|
|
| |
object allocs
|
| |
|