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.

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

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.

Just for consitency. alias_method is easier to reason about than
only_deleted.

In rails 4.x this passed around a set of arel conditions, in rails 5 it
passes around an AR::Relation and uses where().

See rails/rails@5f521cbff3c8a46cfc8e16b234294a20c285d00d

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

For some reason in ruby 2.3 this definition was interpreted as private.
There was no reason to be defining it where it was, so I've moved it
into the paranoia module.

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.

Ruby 1.9's version of `Object.const_get` does not support namespaced constants, so this commit replaces it with `ActiveSupport`'s `#constantize` method.

The tests were failing running JRuby on 1.9 mode. CRuby was not failing because it is not tested against 1.9.

Fixes #114

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

This has been removed and should no longer exist.
https://github.com/radar/paranoia/pull/192#discussion_r24884921

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

This is a workaround actually. Since
`ActiveRecord::CounterCache.each_counter_cached_associations` is
private. We shouldn’t use it. Proposals for the proper fix are welcome.

The reason the previous version stopped working is `affected_rows`
returns `0` at
[active_record/counter_cache.rb#L142](https://github.com/rails/rails/blo
b/ef99d4cd3ecc58a8c1484740b2fb5447dbda23ab/activerecord/lib/active_recor
d/counter_cache.rb#L142). If you follow the method call you’ll find
that it’s called at
[active_record/persistence.rb#L486](https://github.com/rails/rails/blob/
ef99d4cd3ecc58a8c1484740b2fb5447dbda23ab/activerecord/lib/active_record/
persistence.rb#L486). Probably we’d better override the return value in
`ActiveRecord::Relation.delete_all` at
[active_record/relation.rb#L481](https://github.com/rails/rails/blob/ef9
9d4cd3ecc58a8c1484740b2fb5447dbda23ab/activerecord/lib/active_record/rel
ation.rb#L481).