It may be necessary to add unit tests for nested join/preload. For generics API, how should we reuse it? (Similar to the original Session)

There are two ways to reuse db:

1. Just share the db var with condition, as shown in this test https://github.com/go-gorm/gorm/blob/generics/tests/generics_test.go#L758-L771 , which no longer causes any DB pollution issues.

2. Using Scopes to reuse code — though I'm still thinking about whether there's a better way to implement this.

Do you have any suggestions?

There are two ways to reuse db:

1. Just share the db var with condition, as shown in this test generics/tests/generics_test.go#L758-L771 , which no longer causes any DB pollution issues.
2. Using Scopes to reuse code — though I'm still thinking about whether there's a better way to implement this.

Do you have any suggestions?

II think the generics API is simple enough without polluting the db.

I am currently adopting to the generics branch and noticed that there is no .ToSQL() method. Would be nice to see that added as well, to basicly stay method compatible with the old api.
Edit: .Save(), .Pluck() and .FirstOrCreate() are also missing

I am currently adopting to the generics branch and noticed that there is no .ToSQL() method. Would be nice to see that added as well, to basicly stay method compatible with the old api. Edit: .Save() and .FirstOrCreate() are also missing

@NeariX67 you can write it like this https://github.com/go-gorm/gorm/blob/generics/tests/generics_test.go#L842-L847

@jinzhu Are you going to implement FirstOrCreate, Pluck, Create (for multiple objects, without batches) and Save for this generics API?

@jinzhu Are you going to implement FirstOrCreate, Pluck, Create (for multiple objects, without batches) and Save for this generics API?

We are not planning to implement those methods. FirstOrCreate and Save are convenience APIs, but they can be misleading — for example, they don’t handle concurrency issues well. It's often better to write more explicit and meaningful code instead.

Also, for Pluck, you can use Select with Scan; and for batch creation, you can use CreateInBatches based on the length of your data to control the batch size manually.

With the generics API, our goal is to take a more restrained approach to API design to help avoid potential misuse.

@jinzhu A small bug that prevents the correct execution of Updates;

Updates(ctx context.Context, t T) (rowsAffected int, err error)

should be a pointer like so;

Updates(ctx context.Context, t *T) (rowsAffected int, err error)

This doesn't show up as a mistake because the internal Updates receives an interface{}

Noticed that as well. With some objects it will work fine, but some require a pointer and it will throw an error. I have not yet figured out what caused this.
Workaround:

gorm.G[*User](DB).Updates(ctx, &user)

Transaction would logically also be a feature for Generics? So that the tx is referring to the generic Interface object instead of the whole db object. Or am I looking at this incorrectly?

@jinzhu A small bug that prevents the correct execution of Updates;

Updates(ctx context.Context, t T) (rowsAffected int, err error)

should be a pointer like so;

Updates(ctx context.Context, t *T) (rowsAffected int, err error)

This doesn't show up as a mistake because the internal Updates receives an interface{}

What issue might occur if a pointer is not passed in?

Transaction would logically also be a feature for Generics? So that the tx is referring to the generic Interface object instead of the whole db object. Or am I looking at this incorrectly?

Transactions are used like this: https://github.com/go-gorm/gorm/blob/master/tests/generics_test.go#L813-L819

or

db.Transaction(func(tx *DB) error {
    users, err gorm.G[User](tx).Find(ctx)
    return err
})

@jinzhu A small bug that prevents the correct execution of Updates;
Updates(ctx context.Context, t T) (rowsAffected int, err error)
should be a pointer like so;
Updates(ctx context.Context, t *T) (rowsAffected int, err error)
This doesn't show up as a mistake because the internal Updates receives an interface{}

What issue might occur if a pointer is not passed in?

The error that the library throws is explicitly that it expects to receive a pointer to a struct in the Updates method internals. For example my User Store's Upsert method;

func (s *Store) Upsert(data *model.User, userID uint) error {
	ctx := context.WithValue(context.Background(), model.UserIDKey, userID)

	if data.ID == 0 {
		return errors.Trace(s.creatorDB.Create(ctx, data))
	}

	rowsAffected, err := s.updaterDB.Updates(ctx, data)
	if err != nil {
		return errors.Trace(err)
	}

	if rowsAffected == 0 {
		return errors.Trace(ErrUpsertDidntModifyData)
	}

	return nil
}

If I call s.updaterDB.Updates(ctx, data) as s.updaterDB.Updates(ctx, *data) then it will throw that error.

Also the Association is not available on purpose in Generics? Like so in the normal style;

	if err := s.osDeleterDB.WithContext(ctx).Model(&data).Association("GameGameOSs").
		Delete(operatingSystem); err != nil {
		return errors.Trace(err)
	}

@jinzhu A small bug that prevents the correct execution of Updates;
Updates(ctx context.Context, t T) (rowsAffected int, err error)
should be a pointer like so;
Updates(ctx context.Context, t *T) (rowsAffected int, err error)
This doesn't show up as a mistake because the internal Updates receives an interface{}

What issue might occur if a pointer is not passed in?

The error that the library throws is explicitly that it expects to receive a pointer to a struct in the Updates method internals. For example my User Store's Upsert method;

func (s *Store) Upsert(data *model.User, userID uint) error {
	ctx := context.WithValue(context.Background(), model.UserIDKey, userID)

	if data.ID == 0 {
		return errors.Trace(s.creatorDB.Create(ctx, data))
	}

	rowsAffected, err := s.updaterDB.Updates(ctx, data)
	if err != nil {
		return errors.Trace(err)
	}

	if rowsAffected == 0 {
		return errors.Trace(ErrUpsertDidntModifyData)
	}

	return nil
}

If I call s.updaterDB.Updates(ctx, data) as s.updaterDB.Updates(ctx, *data) then it will throw that error.

Can you write a playground PR that reproduce the issue? https://github.com/go-gorm/playground/pulls

Seems it works for this test case https://github.com/go-gorm/gorm/blob/master/tests/generics_test.go#L144

Also the Association is not available on purpose in Generics? Like so in the normal style;

	if err := s.osDeleterDB.WithContext(ctx).Model(&data).Association("GameGameOSs").
		Delete(operatingSystem); err != nil {
		return errors.Trace(err)
	}

Yes, it’s not included yet—I’m still considering if there’s a better way to handle associations.