Mainly around `nil`

[ci skip]

In order to fix issue #17621 we added a check to validations that
determined if a record should be validated. Based on the existing tests
and behavior we wanted we determined the best way to do that was by
checking if `!record.peristed? || record.changed? || record.marked_for_destruction?`

This change didn't make it into a release until now. When #23790 was
opened we realized that `valid?` and `invalid?` were broken and did not
work on persisted records because of the `!record.persisted?`.

While there is still a bug that #17621 brought up, this change was too
drastic and should not be a RC blocker. I will work on fixing this so
that we don't break `valid?` but also aren't validating parent records
through child records if that parent record is validate false. This
change removes the code changes to validate and the corresponding tests.
It adds tests for two of the bugs found since Rails 5 beta2 release.

Fixes #17621

Fixes #23645

When you're using an `attr_accessor` for a record instead of an
attribute in the database there's no way for the record to know if it
has `changed?` unless you tell it `attribute_will_change!("attribute")`.

The change made in 27aa4dda updated validations to check if a record was
`changed?` or `marked_for_destruction?` or not `persisted?`. It did not
take into account virtual attributes that do not affect the model's
dirty status.

The only way to fix this is to always validate the record if the
attribute does not belong to the set of attributes the record expects
(in `record.attributes`) because virtual attributes will not be in that
hash.

I think we should consider deprecating this particular behavior in the
future and requiring that the user mark the record dirty by noting that
the virtual attribute will change. Unfortunately this isn't easy because
we have no way of knowing that you did the "right thing" in your
application by marking it dirty and will get the deprecation warning
even if you are doing the correct thing.

For now this restores expected behavior when using a virtual attribute
by always validating the record, as well as adds tests for this case.

I was going to add the `!record.attributes.include?(attribute)` to the
`should_validate?` method but `uniqueness` cannot validate a virtual
attribute with nothing to hold on to the attribute. Because of this
`should_validate?` was about to become a very messy method so I decided
to split them up so we can handle it specifically for each case.

The focus of this change is to make the API more accessible.
References to method and classes should be linked to make it easy to
navigate around.

This patch makes exzessiv use of `rdoc-ref:` to provide more readable
docs. This makes it possible to document `ActiveRecord::Base#save` even
though the method is within a separate module
`ActiveRecord::Persistence`. The goal here is to bring the API closer to
the actual code that you would write.

This commit only deals with Active Record. The other gems will be
updated accordingly but in different commits. The pass through Active
Record is not completely finished yet. A follow up commit will change
the spots I haven't yet had the time to update.

/cc @fxn

This is a small refactoring that simplifies the Active Record specific
lenght validator.

Without this note, someone can misunderstand the usage of validates_presence_of method

add missing note for the validates_presence_of

Fixes #17621. This 5 year old (or older) issue causes validations to fire
when a parent record has `validate: false` option and a child record is
saved. It's not the responsibility of the model to validate an
associated object unless the object was created or modified by the
parent.

Clean up tests related to validations

`assert_nothing_raised` is not benefiting us in these tests
Corrected spelling of "respects"
It's better to use `assert_not_operator` over `assert !r.valid`

The documentation on `:on` for validations was inconsistent, and most
only referenced the `:create` and `:update` contexts. I fixed those to
be consistent with the documentation on `AM::Validations.validates`,
which seemed to have the best docs.

[ci skip]

Fix habtm reflection
Conflicts:
    activerecord/CHANGELOG.md
    activerecord/lib/active_record/counter_cache.rb
    activerecord/lib/active_record/reflection.rb
    activerecord/test/cases/reflection_test.rb

- since `Array()` calls `to_ary` or `to_a` on a subject
- the intent is to 'wrap' subject into an array

Would incorrectly add duplicated errors when the association was blank. Bug introduced in 1fab518c.

This allows us to mark the parent object as invalid if all associated objects
in a presence validated association are marked for destruction.

See: https://github.com/rails/rails/issues/6812

In order to deliver debug information to dev team
instead of display error message to end user
Implemented strict validation concept
that suppose to define validation that always raise exception when fails

Make ActiveModel::Errors#add_on_blank and #add_on_empty accept an options hash and make various Validators pass their (filtered) options.

This makes it possible to pass additional options through Validators to message generation. E.g. plugin authors want to add validates_presence_of :foo, :format => "some format".

Also, cleanup the :default vs :message options confusion in ActiveModel validation message generation.

Also, deprecate ActiveModel::Errors#add_on_blank(attributes, custom_message) in favor of ActiveModel::Errors#add_on_blank(attributes, options).

Also, refactoring of ActiveModel and ActiveRecord Validation tests. Test are a lot more DRY now. Better test coverage as well now.

The first four points were reapplied from an older patch of Sven Fuchs which didn't apply cleanly anymore and was not complete yet.
Signed-off-by: NJosé Valim <jose.valim@gmail.com>

Revert "Make ActiveModel::Errors#add_on_blank and #add_on_empty accept an options hash and make various Validators pass their (filtered) options."

Having a huge array to whitelist options is not the proper way to handle this case. This means that the ActiveModel::Errors object should know about the options given in *all* validators and break the extensibility added by the validators itself. If the intent is to whitelist options before sending them to I18n, each validator should clean its respective options instead of throwing the responsibility to the Errors object.

This reverts commit bc1c8d58.

Make ActiveModel::Errors#add_on_blank and #add_on_empty accept an options hash and make various Validators pass their (filtered) options.

This makes it possible to pass additional options through Validators to message
generation. E.g. plugin authors want to add validates_presence_of :foo, :format
=> "some format".

Also, cleanup the :default vs :message options confusion in ActiveModel
validation message generation.

Also, deprecate ActiveModel::Errors#add_on_blank(attributes, custom_message) in
favor of ActiveModel::Errors#add_on_blank(attributes, options).

Original patch by Sven Fuchs, some minor changes and has been changed to be applicable to master again

[#4057 state:committed]
Signed-off-by: NJeremy Kemper <jeremy@bitsweat.net>

class Person < ActiveRecord::Base
  include MyValidators

  validates :name, :presence => true, :uniqueness => true, :length => { :maximum => 100 }
  validates :email, :presence => true, :email => true
end

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

Move validations in ActiveModel to validators, however all validatity checks are still in the class method.

Changed ActiveRecord to use new callbacks and speed up observers by only notifying events that are actually being consumed.
Signed-off-by: NJoshua Peek <josh@joshpeek.com>

Signed-off-by: NPratik Naik <pratiknaik@gmail.com>

git-svn-id: http://svn-commit.rubyonrails.org/rails/trunk@9173 5ecf4fe2-1ee6-0310-87b1-e25e094e27de