Distinguish custom types

[black-06]

• Do only one thing
• Non breaking API changes
• Tested

What did this pull request do?

Distinguish between detected and custom type (#6033).
In driver, we will skip to getSchemaCustomType if CustomDataType is specified.
See MySQL#109 for more context.

User Case Description

type Test struct {
    Date time.Time `gorm:"type:date"`
    Time time.Time `gorm:"type:time"`
    DefaultDateTime time.Time
}

CREATE TABLE `tests` (`date` date,`time` time,`default_date_time` datetime)

[jinzhu]

Currently, seems like the field.IsTaggedType field is equal to checking the existing field.TagSettings["TYPE"]?

If so, it doesn't really make sense to have it?

[a631807682]

Currently, seems like the field.IsTaggedType field is equal to checking the existing field.TagSettings["TYPE"]?

If so, it doesn't really make sense to have it?

This is the same thing. I hope to describe all the field information in parse. It is not easy to understand the field.TagSettings["type"] and field.DataTyp in the driver, we need to see the gorm code to know why we do this.

[jinzhu]

Currently, seems like the field.IsTaggedType field is equal to checking the existing field.TagSettings["TYPE"]?
If so, it doesn't really make sense to have it?

This is the same thing. I hope to describe all the field information in parse. It is not easy to understand the field.TagSettings["type"] and field.DataTyp in the driver, we need to see the gorm code to know why we do this.

The Schema and Field was thought of as low-level API, users need to know the details to use them.

But I understand your concerns, maybe we can define some development rules, and have a field to describe those information if it is used for two or three different purposes to avoid API overbloat？

[a631807682]

Currently, seems like the field.IsTaggedType field is equal to checking the existing field.TagSettings["TYPE"]?
If so, it doesn't really make sense to have it?

This is the same thing. I hope to describe all the field information in parse. It is not easy to understand the field.TagSettings["type"] and field.DataTyp in the driver, we need to see the gorm code to know why we do this.

The Schema and Field was thought of as low-level API, users need to know the details to use them.

But I understand your concerns, maybe we can define some development rules, and have a field to describe those information if it is used for two or three different purposes to avoid API overbloat？

I agree

[black-06]

Currently, seems like the field.IsTaggedType field is equal to checking the existing field.TagSettings["TYPE"]?
If so, it doesn't really make sense to have it?

This is the same thing. I hope to describe all the field information in parse. It is not easy to understand the field.TagSettings["type"] and field.DataTyp in the driver, we need to see the gorm code to know why we do this.

The Schema and Field was thought of as low-level API, users need to know the details to use them.
But I understand your concerns, maybe we can define some development rules, and have a field to describe those information if it is used for two or three different purposes to avoid API overbloat？

I agree

Close it?