Add a without_deleted scope to manually exclude paranoia-deleted records, which is essentially the paranoia_scope.
Useful when using the option :without_default_scope or the unscoping of a paranoia-model was required.
Aliased it to the paranoia_scope as opposed to the existing with_deleted scope.

It is unnecessary to test the AR internals here. Testing the
where_values_hash should be sufficient.

alias defines these on ActiveRecord::Base itself, which is not what was
intended. This behaviour previous differed between MRI and jruby.

* Rely on bundler/setup to setup the load paths

Use update_columns rather than touch to update the record, for
generality

Unlike touch, update_columns does not create a transaction for
itself, so we need to add the record to the transaction, if present.
If there is not a current_transaction, the add is a no-op.

This all means that delete will not invoke a transaction or run the
after_commit callbacks unless called from within one, which is
consistent with the Rails docs and the behavior of
ActiveRecord::Base#delete.

Use association.klass.name instead of association.class_name to get the
namespaced class name and therefore prevent:

`Object.get_const(association_class_name)`

from raising "uninitialized constant ParanoidHasOne"
in the following situation:

module Something
  def self.table_name_prefix
    "something_"
  end

  class ParanoidHasOne < ActiveRecord::Base
    acts_as_paranoid
    has_one :paranoid_belongs_to, dependent: :destroy
  end

  class ParanoidBelongsTo < ActiveRecord::Base
    acts_as_paranoid
    belongs_to :paranoid_has_one
  end
end

hasOne = Namespaced::ParanoidHasOne.create
hasOne.destroy
hasOne.restore(:recursive => true) # previously would explode

I asked about `restore` in the
[Notes](https://github.com/radar/paranoia/pull/192#issue-51914917) of
the PR's description. Personally I don't need such a behaviour. So
removing.

This will allow to detect counter cached columns changes in callbacks
like `after_destroy` or `after_commit on: :destroy`.

My goal is Rails 4.2 support and it works well with Rails 4.2. I’m
leaving this bug not fixed for Rails 4.1 for the time being.

This is a test for a case when a model has a has_one association with an
after_validation callback, and we have failed validation. Paranoia will
attempt to touch the deleted_at column on the child record that has
been built but not saved.

Fixes #180

This allows testing rails 4.0 on ruby 2.2

We no longer have different behaviour between AR versions.

Thanks @kidlab

There was a change in ActiveRecord#update_columns on latest rails
so now it checks for `destroyed?` instead of `persisted?`. Paranoia
can't override `destoyed?` like this anymore otherwise
`update_columns` will always raise:

        ActiveRecord::ActiveRecordError: cannot update a destroyed record

see https://github.com/rails/rails/commit/0f99aa615e11c50cc64b567f54cf64f59108c5e5

To ensure that we are using the association _type in our scope.

Restoring polymorphic has_one relationships errored because paranoia was
not correctly looking up the foreign_key.

Output from failing test -

ActiveRecord::StatementInvalid: SQLite3::SQLException: no such column: parent_model_id: SELECT  "polymorphic_models".* FROM "polymorphic_models" WHERE ("polymorphic_models"."deleted_at" IS NOT NULL) AND (parent_model_id)  ORDER BY "polymorphic_models"."id" ASC LIMIT 1

The test sets up a PolymorphicModel, which has_many parents. The
ParentModel then has a has_one relationship with PolymorphicModel. When
restoring, the foreign key is set as - `self.class.name.to_s.underscore_id`
which will be parent_model_id, instead of the :as option.

DEPRECATION WARNING: Currently, Active Record suppresses errors raised within `after_rollback`/`after_commit` callbacks and only print them to the logs. In the next version, these errors will no longer be suppressed. Instead, the errors will propagate normally just like in other Active Record callbacks.

apply the deprecation fix for ActiveRecord >= 4.2 only

DEPRECATION WARNING: You are passing an instance of ActiveRecord::Base to `find`. Please pass the id of the object by calling `.id`. (called from block in restore at /Users/sergey/ruby_projects/paranoia/lib/paranoia.rb:38)

Change-Id: Ib73e43a5adcb8bd9b5bbf5b7ca60f9865e5415e7

Regression from 6881e750

We need to be able to load our class definitions without having an
available database connection.