PHP-Redakteur Dies liegt daran, dass Gorm beim Durchführen einer Abfrage SQL-Anweisungen basierend auf der Reihenfolge der Felder in der Struktur generiert. Wenn wir in der Abfrage eine bestimmte Spaltenreihenfolge angeben, die Feldreihenfolge in der Struktur jedoch nicht damit übereinstimmt, schlägt der Test fehl. Daher müssen wir bei der Verwendung von Gorm für Datenbankabfragen darauf achten, dass die Reihenfolge der Felder in der Struktur mit der Reihenfolge der Spalten in der Abfrage übereinstimmt, um dieses Problem zu vermeiden.
In meinem Code habe ich das folgende Modell:
type ID uint64 type BaseModel struct { ID ID `gorm:"column:id;primaryKey;autoIncrement" json:"id"` UpdateDate time.Time `gorm:"column:update_date;default:CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP" json:"update_date"` CreateDate time.Time `gorm:"column:create_date;default:CURRENT_TIMESTAMP" json:"create_date"` } type Rollback struct { BaseModel PID ID `gorm:"index"` Table string `gorm:"column:tbl_name"` RollbackRow string `gorm:"type:longtext"` }
Ich verwende die gorm.DB
结构的 CreateInBatches
-Methode.
Ich verwende go-sqlmock für Unit-Tests. In diesem Modell werden nur Einfügevorgänge ausgeführt.
func expectRollbackInsert(mock sqlmock.Sqlmock, tablename []string) { args := make([]driver.Value, 0) for _, val := range tablename { args = append(args, 1, val, sqlmock.AnyArg(), sqlmock.AnyArg(), sqlmock.AnyArg()) } mock.ExpectExec(regexp.QuoteMeta("INSERT INTO `rollback` (`payment_id`,`tbl_name`,`rollback_row`,`update_date`,`create_date`) VALUES (?,?,?,?,?)")). WithArgs(args...). WillReturnResult(sqlmock.NewResult(int64(len(tablename)), int64(len(tablename)))) }
Meine Testfälle schlagen manchmal aufgrund der unterschiedlichen Reihenfolge von create_date
和 update_date
fehl.
Einer der Fehler ist
ExecQuery: could not match actual sql: "INSERT INTO `rollback` (`pid`,`tbl_name`,`rollback_row`,`create_date`,`update_date`) VALUES (?,?,?,?,?),(?,?,?,?,?),(?,?,?,?,?),(?,?,?,?,?),(?,?,?,?,?),(?,?,?,?,?),(?,?,?,?,?),(?,?,?,?,?),(?,?,?,?,?),(?,?,?,?,?),(?,?,?,?,?),(?,?,?,?,?),(?,?,?,?,?),(?,?,?,?,?),(?,?,?,?,?),(?,?,?,?,?),(?,?,?,?,?),(?,?,?,?,?),(?,?,?,?,?),(?,?,?,?,?)" with expected regexp "INSERT INTO `rollback` \(`pid`,`tbl_name`,`rollback_row`,`update_date`,`create_date`\) VALUES \(\?,\?,\?,\?,\?\)"
Für meinen Anwendungsfall spielt die Reihenfolge der Spalten in der Einfügung keine Rolle. Wie kann ich damit in Unit-Tests umgehen, um alle Szenarien zu bewältigen?
Nachdem ich die SQLMock-Dokumentation hier gelesen hatte, bekam ich den folgenden Workaround:
func expectRollbackInsert(mock sqlmock.Sqlmock, tablename []string) { args := make([]driver.Value, 0) for _, val := range tablename { args = append(args, 1, val, sqlmock.AnyArg(), sqlmock.AnyArg(), sqlmock.AnyArg()) } mock.ExpectExec(regexp.QuoteMeta("INSERT INTO `rollback`")). WithArgs(args...). WillReturnResult(sqlmock.NewResult(int64(len(tablename)), int64(len(tablename)))) }
Ich habe die Spalten und Werte gelöscht. In meinem Fall muss ich mich nicht um das Feld create_date
和 update_date
kümmern, also funktioniert es einwandfrei.
Das obige ist der detaillierte Inhalt vonGorm unterschiedliche Spaltenreihenfolge und Testfehler. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!