about the execution order of the `BeforeDelete` hook when performing a soft delete

[Iristack]

Your Question

Hi everyone,

I'm encountering an issue while using GORM's soft delete feature.

I have a field defined like this:

DeletedAt gorm.DeletedAt `gorm:"column:deleted_at;index"`

And a hook like this:

func (t *TenantInfo) BeforeDelete(tx *gorm.DB) error {
    if currentUser, ok := getCurrentUserFromContext(tx); ok {
        t.DeletedBy = currentUser
    }
    return nil
}

I want to record the user who performed the deletion during the delete operation. However, I noticed that the actual SQL being executed is:

UPDATE `table_name` SET `deleted_at`="2026-01-14 19:32:47.266" WHERE `table_name`.`id` = 9 AND `table_name`.`deleted_at` IS NULL

This is my deletion code:

if err := databases.GetDB().WithContext(ctx).Delete(&tenant).Error; err != nil {
    logger.GetRuntime().Error("delete tenant failed", zap.Error(err))
    return
}

The update does not include the changes I made in the BeforeDelete hook (e.g., setting DeletedBy).
I also tried fetching the record first and then deleting it, but the same issue persists.

Is this behavior expected? And are there any alternative solutions or workarounds?

[qqxhb]

This is expected: with GORM’s built-in soft delete, Delete is transformed into an UPDATE that sets only the soft-delete column (e.g. deleted_at / flag). Mutating other fields in BeforeDelete doesn’t automatically add them into the generated SET clause.

If you want to update extra columns in the same soft-delete UPDATE (e.g. deleted_by, deleted_reason, etc.), we proposed adding support in the gorm.io/plugin/soft_delete plugin:

PR: go-gorm/soft_delete#21

Usage:

• Tag the soft-delete field with extra columns:
  gorm:"softDelete:flag,ExtraFields:DeletedBy;DeletedReason"
• Pass values via statement settings:
  db.Set(soft_delete.ExtraSettingsKey, map[string]interface{}{"DeletedBy": userID}).Delete(&obj)
• Or set from BeforeDelete hook:
  soft_delete.SetExtra(tx, map[string]interface{}{"DeletedBy": userID})

This keeps the operation single-SQL while keeping the extra values explicit (no hidden queries).