go-gorm/gorm

Rationale for the DryRun guard on callbacks.RowQuery

Open

#6222 opened on Apr 8, 2023

View on GitHub
 (2 comments) (0 reactions) (1 assignee)Go (39,750 stars) (4,145 forks)batch import
help wantedstatus:staletype:question

Description

Your Question

TL;DR: can you tell me why callbacks.RowQuery is not supported in dry run mode? Is there a possibility (I'm happy to contribute a PR) that it could support dry run mode?

Use case

My use case is to use DryRun to capture table creation DDL with Migrator running in dry mode. A promising approach has been to implement a custom logger to capture the generated SQL to an io sink (I've also tried wrapping a Dialector) but otherwise leave the target database's state alone (i.e. dry mode).

Blocker

However, this approach seems incompatible with callbacks.RowQuery, which guards the write to Statement.Dest with a if !db.DryRun block†. The presence of this guard implies that callbacks.RowQuery is generally incompatible with dry mode, and I'm wondering if you can tell me why that is? I just don't have enough experience with Gorm to reason about why that might be the case.

†(this actually causes a panic because the finisher_api's func (db *DB) Row() *sql.Row will return a nil *sql.Row instead of populating a *sql.Row with an error)

The document you expected this should be explained

This is a pretty low-level question, and might be my ignorance. So I don't expect it to be documented. For reference I did read the following:

Expected answer

That callbacks.RowQuery is compatible with dry run, you just need a PR and some tests :)

Contributor guide