Why restrict the primary key of sharding to int64 and must be called "ID"

[DuskDrum]

Why restrict the primary key of sharding to int64 and must be called "ID"

I am using the latest version 0.5.3 of gorm sharding and have encountered two issues with primary keys.
Problem 1: When inserting, a primary key will be generated based on the suffix. My suffix is not a number, which causes the insert to fail (such as line 363 of the sharding.go source code image). The solution comes from rows 357 and 358, but my table primary key is not called "ID" but "order_id". Is there a way to skip the error of row 363.

Question 2: When querying, if there is an "id" field, it must be of type int64, otherwise it will cause an error in line 486. Is there a way to skip this judgment and successfully query

Expected answer

I want to know if there is a way to bypass the limitation of gorm sharing for primary keys that are "ID" and of type int64

[cachalots]

I solved this by renaming the primary key column name to id, it's just needs you to have the id column and doesn't care if it's of type int. I don't understand why there must be an id column instead of customizing this column name.

[egandro]

Same question - why not allow UUIDs?

It can be modul'ed 32,64,128... and can then create orders_0 ... orders_127