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

From 2c667f69.

Thanks @pwnall for the heads-up.

This reverts commit 21eadc1b.

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.

Instead of generating association methods directly in the model
class, they are generated in an anonymous module which
is then included in the model class. There is one such module
for each association. The only subtlety is that the
generated_attributes_methods module (from ActiveModel) must
be forced to be included before association methods are created
so that attribute methods will not shadow association methods.

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.

Move ActiveModel::AttributeMethods#attribute_methods_generated? to ActiveRecord, so it's flexible now

[#6428 state:resolved]
Signed-off-by: NJosé Valim <jose.valim@gmail.com>

Work around a strange piece of Syck behaviour where it checks Model#respond_to? before initializing the object.

Things like YAML.load(YAML.dump(@post)) won't work without this.