Skip to content

A question regarding the logic of the Select methods (All in particular) #68

@preslavrachev

Description

@preslavrachev

@jirfag great project and I am glad I found it even though this late.

I have one question though. With respect to code readability, does it make sense to copy gorm's way of accepting a result pointer as an argument?

What I mean is the following. Every QuerySet instance has one of these methods:

func (qs UserQuerySet) All(ret *[]User) error {
	return qs.db.Find(ret).Error
}

I allowed myself to insert a second method that looks one idea cleaner if you are coming from other languages:

func (qs UserQuerySet) AllRet() ([]User, error) {
	var ret []User
	err := qs.db.Find(&ret).Error
	return ret, err
}

Since I don't want to make false claims, I also wrote a quick benchmark testing each and every method with the same conditions (10000 mock users benching for 5s). Here are the results:

BenchmarkUserSelectAll-8   	      361764	     14977 ns/op	    6154 B/op	     100 allocs/op
BenchmarkUserSelectAllRet-8   368132	     14634 ns/op	    6153 B/op	     100 allocs/op

Without going as far as to claim that my method is faster, I'd just say they are on par with one another. What was then the motivation to follow the result pointer approach? Could we make an improvement proposal in the future?

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions