fix(database/gdb): Resolved the schema error in the database output log when using the database sharding feature

[LanceAdd]

error log

2025-06-18T15:36:08.315+08:00 [DEBU] {10a3b0cfd9124a186b89b07f50e67ce6} [  0 ms] [default] [db_0] [rows:1  ] SELECT `id`,`custom_name` FROM `custom` WHERE `id`=1 LIMIT 1

2025-06-18T15:36:09.259+08:00 [DEBU] {10a3b0cfd9124a186b89b07f50e67ce6} [  1 ms] [default] [db_0] [rows:1  ] SELECT `id`,`custom_name`,`remark`FROM `custom` WHERE `id`=2 LIMIT 1

right log

2025-06-18T15:36:08.315+08:00 [DEBU] {10a3b0cfd9124a186b89b07f50e67ce6} [  0 ms] [default] [db_0] [rows:1  ] SELECT `id`,`custom_name` FROM `custom` WHERE `id`=1 LIMIT 1

2025-06-18T15:36:09.259+08:00 [DEBU] {10a3b0cfd9124a186b89b07f50e67ce6} [  1 ms] [default] [db_1] [rows:1  ] SELECT `id`,`custom_name`,`remark`FROM `custom` WHERE `id`=2 LIMIT 1

type DbShardingRule struct {
}

func (d *DbShardingRule) SchemaName(ctx context.Context, config gdb.ShardingSchemaConfig, value any) (string, error) {
	if name, ok := value.(string); ok && (len(name) > 0) && gstr.HasPrefix(name, config.Prefix) {
		return name, nil
	}
	return "default", nil
}

func (d *DbShardingRule) TableName(ctx context.Context, config gdb.ShardingTableConfig, value any) (string, error) {
	return "", nil
}

config := gdb.ShardingConfig{
		Schema: gdb.ShardingSchemaConfig{
			Enable: true,
			Prefix: "db_",
			Rule:   &DbShardingRule{},
		},
	}
dao.Custom.Ctx(ctx).Sharding(config).ShardingValue("db_0").Where("id", 1).One()
dao.Custom.Ctx(ctx).Sharding(config).ShardingValue("db_1").Where("id", 2).One()

我有两个完全一样的数据库db_0和db_1，两个custom表里都只有一条数据，id是1和2，执行上面两条查询得的结果是正确的，
输出日志中应该分别是[default] [db_0]和[default] [db_1]，但是实际输出的都是[default] [db_0]，
查看具体代码实现，该日志由Core实例中获取group和schema构成，而实际执行sql时如果使用了分库特性那么执行sql的link会使用当前面schema重新生成，但是没有重新赋给Core实例，所以输出日志的时候还是错的，只需要在生成link后生成日志前把schema赋给Core就行，方法执行完成后defer将schema重置回去，防止有人重复使用同一个gdb对象造成困扰

[Copilot]

Pull Request Overview

This PR fixes a bug in database sharding where the schema name was incorrectly logged in database operations when using the sharding feature. The issue was that while the SQL execution used the correct sharded schema, the logging output still showed the original schema name instead of the dynamically determined one.

• Temporarily updates the Core schema to match the sharded schema during database operations
• Adds defer statements to restore the original schema after operations complete
• Ensures log output correctly reflects the actual database schema being used

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[Copilot]

Direct assignment to the Core schema without synchronization could cause race conditions if multiple goroutines access the same database instance simultaneously. Consider using atomic operations or mutex protection for the schema field access.

[Copilot]

The schema restoration logic is duplicated across all four hook methods. Consider extracting this into a helper method to reduce code duplication and improve maintainability.

[Copilot]

The schema restoration logic is duplicated across all four hook methods. Consider extracting this into a helper method to reduce code duplication and improve maintainability.

[Copilot]

The schema restoration logic is duplicated across all four hook methods. Consider extracting this into a helper method to reduce code duplication and improve maintainability.

[Copilot]

The schema restoration logic is duplicated across all four hook methods. Consider extracting this into a helper method to reduce code duplication and improve maintainability.