This reverts commit 4004bd5e.

This reverts commit 6881e750.

see https://github.com/radar/paranoia/issues/169

refs https://github.com/radar/paranoia/issues/102

This appears to be a Rails ~> 4.0.8 bug, which is seemingly fixed in Rails 4.1.

Use fetch for sentinel_value

Use DateTime for sentinel_value example

Use an epoch. rails convers '0' or 0 to nil for datetime fields

Add test for restore

Update readme

Move MYSQL note to bottom of readme

update destroyed? for sentinel value

This reverts commit 566b1cbd.

Conflicts:
	README.md
	test/paranoia_test.rb

Fixes #149

Fixes #148

touch_paranoia_column before really_destroy!-ing a record in rails 4.1.x. reloading already really_destroy!-ed associations is needed, otherwise super.destroy! will try to destroy these asociations (because they still exist on the activerecord object, but are already removed from the database)

Fixes #143

FIX: reflections have been reworked in rails 4.1.2 - reflections is no longer available on activerecord objects, only on the class.

Fixes #143

Fixes #138

when the model has_one use class_name or foreign_key, restore use
class_name or setting the foreign_key.

Fixes #117

Fixes #126

Fixes #125

  * Based on partial fix by @stupergenius
  * Handles nil case for hasOne associations

Fixes #119

Rails normally returns the model on successful destroy and false if any
callback fails.

Fixes #104

Fixes #95

This is because destroy! is called by :dependent => :destroy association definitions (yes, destroy! and not destroy), which means that associated records of a paranoid object would suddenly go missing... making it very hard to restore them!

So instead, it's now called really_destroy! and destroy! is just an alias for destroy once again

As per #92

Fixes #91

Fixes #81
Fixes #84

Conflicts:
	lib/paranoia.rb

References: https://github.com/goncalossilva/acts_as_paranoid

Fixes #76