Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
preslavrachev opened this issue Aug 11, 2021 · 0 comments

Comments

@preslavrachev
Copy link

preslavrachev commented Aug 11, 2021

@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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant