Gorm Make Order Func Support Custom String Type

Describe the feature

can we just make order func support custom string type?

type TableAOrderBy string
var orderBy TableAOrderBy = "id desc"
db.Order(orderBy) // make it work

Motivation

Sometimes we might custom an string type and use it to order in gorm, for example

type TableAOrderBy string

type SomeQuery struct {
    QueryFields interface{}
    OrderBy TableAOrderBy

func (p *Repo) Query(ctx context.Context, args SomeQuery) ([]interface{}, error) {
    var res []interface{}
    // order by not working here as its type neither string or clause.OrderByColumn
    // see this link: https://github.com/go-gorm/gorm/blob/master/chainable_api.go#L229
    err := p.db.WithContext(ctx).Order(args.OrderBy).Find(&res).Error
    return res, err
}

So it may cause bugs.

I create this issue just for communication, if you think it can be added into gorm, I would like to have a PR.

Related Issues

Comment From: github-actions[bot]

The issue has been automatically marked as stale as it missing playground pull request link, which is important to help others understand your issue effectively and make sure the issue hasn't been fixed on latest master, checkout https://github.com/go-gorm/playground for details. it will be closed in 30 days if no further activity occurs. if you are asking question, please use the Question template, most likely your question already answered https://github.com/go-gorm/gorm/issues or described in the document https://gorm.io ✨ Search Before Asking ✨

Comment From: v-wiil

use reflect to get the kind of OrderBy？

Comment From: ivila

use reflect to get the kind of OrderBy？

I think it could be a solution, moreover, we might need to add an extra log or error to notify dev about that his codes doesn't work here(in the situation that dev doesn't pass a valid order by, for example, passing a slice).

// dev passing something that won't be handled by Order Func
// we should notify dev about that his codes doesn't work
p.db.WithContext(ctx).Order([1,2,3,4,5])

Comment From: icpd

Just convert it to string. Why impose uncertainty on gorm?

Comment From: ivila

Just convert it to string. Why impose uncertainty on GORM?

Sometimes you may not aware of that you pass a non-string. For example, you have a function which take an orderBy argument, and some day a developer change its type to an enum type(origin type still a string) for readability and type safe(prevent from passing wrong string), and magically you codes run without any error(GORM didn't return error when your codes doesn't work). So I think we need at least one of the followings: 1, make it work: Make Order Func support it.

type EnumOrderBy string
const (
    orderByID EnumOrderBy = "id DESC"
)
func CallWithOrderBy(ctx context.Context, orderBy EnumOrderBy) ([]interface{}, error) {
    var dest []interface{}
    err := gorm.DB.Order(orderBy).Find(&dest).Error
    return dest, err // in this solution, order by should work
}

2, make it an error: Make Order Func set error when your argument doesn't be taken(the default branch, just eat it without any notification).

type EnumOrderBy string
const (
    orderByID EnumOrderBy = "id DESC"
)
func CallWithOrderBy(ctx context.Context, orderBy EnumOrderBy) ([]interface{}, error) {
    var dest []interface{}
    err := gorm.DB.Order(orderBy).Find(&dest).Error
    return dest, err // in this solution, err should not be nil, for notify developer that your orderby not working here.
}

Comment From: a631807682

We won't support it, maybe you want to see the difference between type definitions and type aliases. https://go.dev/ref/spec#Type_declarations

Comment From: ivila

https://go.dev/ref/spec#Type_declarations

I know the difference, and we do a type definition on purpose(if people pass wrong argument, we can prevent it at compile time), but it's OK not to support it.

Comment From: a631807682

@ivila I think supporting it would add complexity to gorm, but not much benefit. For example, if we support it, should we also support map[string]string, or support it in other APIs? I think users can be well supported by Scopes