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

Why always call s.clone #1082

Closed
alanyuen opened this issue Jun 22, 2016 · 3 comments
Closed

Why always call s.clone #1082

alanyuen opened this issue Jun 22, 2016 · 3 comments

Comments

@alanyuen
Copy link

What is the reason?

@qw4990
Copy link

qw4990 commented Sep 23, 2016

Here are my points.

Because gorm uses chainable API, calling db.Func() will return a *DB pointer, so if no s.clone(), user will get two pointers, the original *db and the returned *db, which actually point to the same object.

It is dangerous and may cause some concurrent problems.

@jinzhu jinzhu closed this as completed Apr 18, 2017
@preslavrachev
Copy link

Sorry for opening up that topic again, but I started reading through the Gorm code and it seems like you might benefit from just letting the runtime copy, instead of the library doing it manually. If you use a non-pointer receiver you'll obtain a new copy every time, and still benefit from the chaining.

If interested, have a look at my thoughts in more detail here: https://preslav.me/2019/10/06/simple-immutable-builders-in-go-using-value-receivers/

@nmccready
Copy link

@jinzhu thoughts on last comment?

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

5 participants