This project is no longer maintained. If you would like to become the new owner, please email Winton Welsh.
Don't delete your records, move them to a different table.
acts_as_paranoid, but doesn't mess with your SQL queries.
gem install acts_as_archive
require 'acts_as_archive' class Application < Sinatra::Base include ActsAsArchive::Adapters::Sinatra end
config/acts_as_archive.yml to define the archive class and archive table for each of your models:
Article: - class: Article::Archive table: archived_articles
It is expected that neither the archive class or archive table exist yet.
ActsAsArchive will create these automatically.
rake db:migrate. Your archive table is created automatically.
delete_all like you normally would.
Records move into the archive table instead of being destroyed.
If your model's relationship has the
:dependent option, and the relationship also uses
acts_as_archive, that relationship will archive automatically.
New migrations are automatically applied to the archive table.
No action is necessary on your part.
Use the archive class you specified in the configuration:
Use any of the destroy methods, but add a bang (!):
Article::Archive.first.destroy! Article.delete_all!([ "id in (?)", [ 1, 2, 3 ] ])
Use any of the destroy/delete methods on the archived record to move it back to its original table:
Article::Archive.first.destroy Article::Archive.delete_all([ "id in (?)", [ 1, 2, 3 ] ])
Any relationships that were automatically archived will be restored as well.
You will find an extra
deleted_at datetime column on the archive table.
You may manually add a
restored_at datetime column to the origin table if you wish to store restoration time as well.
Add this line to a migration, or run it via
This copies all records with non-null
deleted_at values to the archive.
There is a wiki entry that describes the development setup in-depth.