Feature Request: Add the automatic type mapping for uint8/16/32/64 and int8/16/32

[gsbingo17]

Developers make code changes to Spanner from MySQL using go-gorm-spanner; Because Spanner does not use unsigned integer type, it causes developers to introduce explicit conversions, creating overhead for application refactoring.

For example:

	testObject := &TestObject{
		Id:                  int64(in.Id),
		TestId:            int64(in.TestId),
		TestType: int64(in.TestType),
		...
	}

Could you please consider the support for automatic type mapping to INT64 from unit/unit8/16/32/64.

[olavloite]

@gsbingo17 uint should automatically be mapped to INT64. The uint8/16/32/64 types are currently not mapped. Is that the issue? Would you otherwise mind elaborating a bit more on exactly what is not working as expected?

Many of the tests in this repository use gorm.Model, which uses uint as the primary key. I've also added this pull request to verify that it is possible to write and read uint values without any conversion: #125

[gsbingo17]

@olavloite Thank you! This feature request addresses a common use case where developers are refactoring applications to migrate from MySQL to Spanner.

• To minimize code changes, developers often focus on updating the data access layer, leaving the business logic and presentation layers largely untouched.

• In this scenario, the business logic and presentation layers continue to use data types like uint8/16/32/64 and int8/16/32, as they did with MySQL. However, the data access layer needs to create structs using Spanner's int64 data type. This creates a challenge: When manipulate data to Spanner, the data access layer must explicitly convert non-int64 types to int64, introducing significant overhead.

• To overcome this, developers would prefer to continue using the same integer types they used in MySQL. GORM Spanner can address this need by providing automatic type conversion, allowing structs to be stored using uint8/16/32/64 and int8/16/32.

[olavloite]

@gsbingo17 Could you supply a code sample for something that you have at the moment that does not work with Spanner? That makes it easier to understand where it goes wrong.

I understand that the desire is to minimize code changes, but it's not entirely clear to me how your structure is at the moment, and where that then causes an issue.

Put another way, based on your original example:

	testObject := &TestObject{
		Id:                  int64(in.Id),
		TestId:            int64(in.TestId),
		TestType: int64(in.TestType),
		...
	}

The above conversions should all not be necessary if in.Id, in.TestId, and in.TestType are of type uint, and you also define the fields of TestObject of type uint. Is the problem specifically that the other types uint8 etc. are not mapped? Or something else?

[gsbingo17]

@olavloite Thank you! I just created a doc and shared it with you.