Is your feature request related to a problem?
Option Yes
Describe the solution you'd like
建议面向数据库字段级增加类型转换器的配置，这个转换器将比通用类型转换器有更高的优先级，一旦配置，将会忽略所有类型转换方法，直接进入转换器处理。比如忽略String() Value()等。
解决问题：
在一些特殊情况下，orm的的默认转换规则会带来很多问题，但却无法解决。比如在MYSQL中存放uuidv7 ，我们知道uuidv7的优势就是时间有序，所以可以很好地支持ID大小比对，排序。但是，这个前提是基于binary(16)来设计，如果用了char(36)。会按字面字符排序，可能效果会很差。但是，我们现在的ORM在传入uuid时，会默认调用String()，就会把它强转成36字符的UUID字符串表示，这在对比binary(16)时，必然会报错。若这个时候有个字段级（指定字段）的最高优先级的转换器存在，则可以将其转换成[]byte，就不会再出现这个问题了。（PS：当前的解决方案，只有在传入时取切片，如uuid[:]，让其转成[]byte，可用，但不够优雅。）同时，我们在取值时，也有类似问题，所以，转换器需要有两个，一个是设置值时用，一个是取值时用。
当然，如果有类似的HOOK可以实现，也希望告知。
Describe alternatives you've considered
先不说通用类型转换能不能用，这里其实是用不上的，就算能用，万一有一处真的是binary(16)，却不是uuid，那也会出问题。
Additional
No response
Is your feature request related to a problem?
Option Yes
Describe the solution you'd like
建议面向数据库字段级增加类型转换器的配置，这个转换器将比通用类型转换器有更高的优先级，一旦配置，将会忽略所有类型转换方法，直接进入转换器处理。比如忽略String() Value()等。
解决问题：
在一些特殊情况下，orm的的默认转换规则会带来很多问题，但却无法解决。比如在MYSQL中存放uuidv7 ，我们知道uuidv7的优势就是时间有序，所以可以很好地支持ID大小比对，排序。但是，这个前提是基于binary(16)来设计，如果用了char(36)。会按字面字符排序，可能效果会很差。但是，我们现在的ORM在传入uuid时，会默认调用String()，就会把它强转成36字符的UUID字符串表示，这在对比binary(16)时，必然会报错。若这个时候有个字段级（指定字段）的最高优先级的转换器存在，则可以将其转换成[]byte，就不会再出现这个问题了。（PS：当前的解决方案，只有在传入时取切片，如uuid[:]，让其转成[]byte，可用，但不够优雅。）同时，我们在取值时，也有类似问题，所以，转换器需要有两个，一个是设置值时用，一个是取值时用。
当然，如果有类似的HOOK可以实现，也希望告知。
Describe alternatives you've considered
先不说通用类型转换能不能用，这里其实是用不上的，就算能用，万一有一处真的是binary(16)，却不是uuid，那也会出问题。
Additional
No response