An ActiveRecord mixin that adds safe soft-delete functionality with timestamps and restoration capabilities.
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.
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.
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.
ActiveRecord Mixin for Safe Destroys
Open-Awesome is built by the community, for the community. Submit a project, suggest an awesome list, or help improve the catalog on GitHub.
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.
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.
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.
Requires only including the gem and adding a database column, with no complex setup needed, as demonstrated in the installation instructions.
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.
Models with dependent: :destroy associations can cause hard deletes if associated models don't include DestroyedAt, requiring careful attention to avoid data loss.
Each model requires a destroyed_at column and potentially indexes, necessitating migrations and database changes, which adds complexity to deployment.