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).

https://github.com/radar/paranoia/blame/1b051ae78793f3b62297b5adbaa9c1d0
0e6726e0/README.md#L154

http://edgeguides.rubyonrails.org/4_2_release_notes.html#active-record-d
eprecations
> Deprecated passing Active Record objects to .find or .exists?. Call
id on the objects first.
Commits in Rails:
https://github.com/rails/rails/commit/d92ae6ccca3bcfd73546d612efaea01127
0bd270
https://github.com/rails/rails/commit/d35f0033c7dec2b8d8b52058fb8db495d4
9596f7
https://github.com/rails/rails/commit/c0609dd0f0f0de604ac1ffeffdf5e3e0e7
356b35

We shouldn't be overriding this. soft-deleted objects are still
persisted.

The default implementation is already destroy || raise

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