How to set up DestroyedAt in a Rails app?

First, add the gem to your Gemfile and run bundle install. Then, include the DestroyedAt module in your ActiveRecord models and create a migration to add a destroyed_at datetime column to the corresponding tables, as per the README.

DestroyedAt vs acts_as_paranoid: which is better for Rails?

DestroyedAt is simpler and more modern, focusing on timestamp-based soft deletes with restoration and callbacks. acts_as_paranoid is older and may have different behavior; choose based on your Rails version and need for minimal dependencies or specific features.

Does DestroyedAt work with Rails 7?

Yes, DestroyedAt is compatible with recent Rails versions, but always check the gem's GitHub page or documentation for specific compatibility notes, as it's actively maintained by DockYard.

How to handle unique emails with DestroyedAt?

You need to modify your uniqueness validators manually, such as validates :email, uniqueness: { conditions: -> { where(destroyed_at: nil) } }, because the gem doesn't automatically adjust Rails' default scoping for validators.

Can I restore multiple records at once with DestroyedAt?

The gem provides instance-level restore methods; for batch restoration, you can iterate over destroyed records using the .destroyed scope and call restore on each, but there's no built-in bulk restore feature.

What are the performance impacts of using DestroyedAt?

Without proper indexing on the destroyed_at column, queries may slow down due to table scans. The README recommends adding indexes, especially for large datasets, to maintain performance.

Open-Awesome

Destroyed At

Ruby

An ActiveRecord mixin that adds safe soft-delete functionality with timestamps and restoration capabilities.

GitHub

345 stars25 forks0 contributors

What is Destroyed At?

DestroyedAt is an ActiveRecord mixin that implements safe soft-delete functionality for Ruby on Rails applications. It replaces permanent record deletion with timestamp-based marking, allowing destroyed records to be restored later while keeping them hidden from default queries. This solves the problem of accidental data loss and provides an audit trail for destroyed items.

Target Audience

Ruby on Rails developers who need to implement soft-delete functionality in their applications, particularly those working with data that requires recovery options or audit trails.

Value Proposition

Developers choose DestroyedAt because it provides a clean, ActiveRecord-native approach to soft deletes with minimal configuration, built-in restoration capabilities, and proper scope management without requiring complex database modifications or external dependencies.

Overview

ActiveRecord Mixin for Safe Destroys

Use Cases

Best For

Implementing soft-delete functionality in Rails applications
Adding data recovery options for user-deleted content
Creating audit trails for destroyed database records
Building applications with regulatory compliance requirements
Preventing accidental data loss in production systems
Managing archived data while keeping it queryable

Not Ideal For

Applications requiring GDPR-compliant hard deletes where data must be permanently erased
Projects with complex, non-ActiveRecord data layers or multiple ORMs
High-performance systems where additional query scopes could degrade speed without careful indexing

Pros & Cons

Pros

Safe Soft Deletes

Overrides ActiveRecord's destroy method to set a destroyed_at timestamp instead of deleting records, preventing data loss and enabling recovery, as shown in the README's destruction example.

Restoration with Callbacks

Provides a restore method to unset timestamps and includes before_restore, after_restore, and around_restore callbacks for custom logic, similar to ActiveRecord's destroy callbacks.

Automatic Scope Management

Adds a default scope to exclude destroyed records and a .destroyed scope for querying them, making it easy to handle both active and archived data without manual SQL.

Minimal Configuration

Requires only including the gem and adding a database column, with no complex setup needed, as demonstrated in the installation instructions.

Cons

Uniqueness Validator Complications

Developers must manually adjust uniqueness validators to exclude destroyed records, as the gem doesn't handle this automatically, adding extra work and potential for errors.

Dependent Destroy Risks

Models with dependent: :destroy associations can cause hard deletes if associated models don't include DestroyedAt, requiring careful attention to avoid data loss.

Database Migration Overhead

Each model requires a destroyed_at column and potentially indexes, necessitating migrations and database changes, which adds complexity to deployment.

Frequently Asked Questions

Related Projects

PaperTrail

Track changes to your rails models

Stars7,028

Forks907

Last commit4 months ago

ActsAsTaggableOn

A tagging plugin for Rails applications that allows for custom tagging along dynamic contexts.

Stars4,988

Forks1,193

Last commit1 month ago

activerecord-import

A library for bulk insertion of data into your database using ActiveRecord.

Stars4,154

Forks620

Last commit11 days ago

Ancestry

Organise ActiveRecord model into a tree structure

Stars3,878

Forks472

Last commit2 months ago

Community-curated · Updated weekly · 100% open source

Found a gem we're missing?

Open-Awesome is built by the community, for the community. Submit a project, suggest an awesome list, or help improve the catalog on GitHub.

Submit a project Star on GitHub