Describe the feature

In callbacks.go you can find the processor.Execute implementation.

Within it, this code:

  if stmt.SQL.Len() > 0 {
    db.Logger.Trace(stmt.Context, curTime, func() (string, int64) {
        sql, vars := stmt.SQL.String(), stmt.Vars
        if filter, ok := db.Logger.(ParamsFilter); ok {
            sql, vars = filter.ParamsFilter(stmt.Context, stmt.SQL.String(), stmt.Vars...)
        }
        return db.Dialector.Explain(sql, vars...), db.RowsAffected
    }, db.Error)
  }

This code allows a custom Logger to implement the ParamsFilter interface, and thus be able to use this strong ability.

In finisher-api.go, the db.Create/Update/Delete/etc.. all use the custom Logger as is when calling Execute. However, db.Scan uses a different logic, and right before calling the underlying logic, it does:

currentLogger, newLogger := config.Logger, logger.Recorder.New()
config.Logger = newLogger

tx = db.getInstance()
tx.Config = &config

This runs over the custom Logger implementation, and uses the default traceRecorder, which does not implement ParamsFilter, nor allows to be extended with such logic.

Motivation

Allow db.Scan to leverage the ParamsFilter interface. With that, PII logging can be avoided.

Related Issues

  1. Found https://github.com/go-gorm/gorm/issues/5287 which was closed for some reason
  2. See PR https://github.com/go-gorm/gorm/pull/7337 with a very naive solution