This removes the assumption from `really_destroy!` that there is
only one column value, the deletion date, that needs to be updated
on a model that is being `really_destroy!`ed. Instead, use the
defined `paranoia_destroy_attributes` as they are used in `destroy`
and other calls.

This prevents an issue where the DBMS will complain when trying to
`really_destroy!` one of these models, given that paranoia is
attempting to insert a DateTime value into a boolean (or otherly-
typed) column.

Fixes #326

Fixes a problem of ambiguous table names when using only_deleted method and joining tables that have a scope on `with_deleted`

Update homepage in gemspec

The homepage is supposed to be where you can find the code. It is displayed on rubygems.org page. Currently it will redirect you back to the same page. Should point at this github repo.

Update README to use proper version for Rails 5

Version 2.2.0

Ignore failures from all jruby's on travis

Add explicit language about dependent: :destroy

Update CHANGELOG.md

update ruby and rails versions

Use ActiveSupport.on_load to correctly re-open ActiveRecord::Base. https://github.com/rubysherpas/paranoia/issues/335

Touch record on paranoia-destroy. Fixes #296

Touch record on destroy by leveraging the paranoia_destroy_attributes.
Applied the same to the restore-method as this eliminates the extra query.

Touch record on destroy by leveraging the paranoia_destroy_attributes.
Applied the same to the restore-method as this eliminates the extra query.

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.