Running second time AutoMigrate fails

[gsbingo17]

The AutoMigrate method on already existing entities does not deal with unique index and the nullable column accurately.

• unique index

package main

import (
	spannergorm "github.com/googleapis/go-gorm-spanner"
	"gorm.io/gorm"

	"gorm.io/gorm/logger"
)

type Apple struct {
	AppleID string `gorm:"primaryKey"`
	Name    string `gorm:"not null;index:idx_name_email,unique"`
	Email   string `gorm:"not null;index:idx_name_email,unique"`
	Age     int
}

func main() {
	// Replace with your actual Cloud Spanner project, instance, and database
	dsn := "projects/your-project-id/instances/your-instance/databases/your-db"

	db, err := gorm.Open(spannergorm.New(spannergorm.Config{
		DriverName: "spanner",
		DSN:        dsn,
	}), &gorm.Config{
		Logger: logger.Default.LogMode(logger.Info),
	})

	if err != nil {
		panic("failed to connect database")
	}

	// AutoMigrate will create the table with the unique indexes
	db.AutoMigrate(&Apple{})
}

Please refer to the following error:

rpc error: code = NotFound desc = uni_apples_name is not a constraint in apples

• nullable column

type Admin struct {
   Id            int64      `gorm:"column:id;primarykey;not null;comment:自增ID"`
   LastLoginTime *time.Time `gorm:"column:last_login_time;null;default:null`
}

Please refer to the following error:

ALTER TABLE `user_admin` ALTER COLUMN `last_login_time` TIMESTAMP DEFAULT (null)

// Add this column again, it is not expected behavior

Environment details

• Programming language: Golang
• OS: MacBook
• Language runtime version: 1.23
• Package version: 1.4.0

Steps to reproduce

1. Execute the sample code;
2. Run it again;
3. Change the sample code to use nullable column, and test it again

Thanks!

[gsbingo17]

The similar issue was encountered to the FLOAT64 column.

When executing the AutoMigrate tool again, it caused unexpected behavior with the existing FLOAT64 column.

ALTER TABLE `table_name` ALTER COLUMN `columne_name` FLOAT64 NOT NULL DEFAULT(0)

[tburgin]

Oh interesting. It seems I was experiencing a variation of this bug. I put a potential fix up for review here #137

I am curious if it also fixes your use cases?

[tburgin]

I am curious if it also fixes your use cases?

Doesn't look like it. I will take a stab at fixing this case as well, when I have time.

As a workaround, I have found this hack works: gorm:"uniqueIndex;unique".