Gorm: Why always call s.clone

Created on 22 Jun 2016  ·  3Comments  ·  Source: go-gorm/gorm

What is the reason?

Most helpful comment

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.

All 3 comments

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.

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/

@jinzhu thoughts on last comment?

Was this page helpful?
0 / 5 - 0 ratings

Related issues

MikeJinhua picture MikeJinhua  ·  14Comments

samgavinio picture samgavinio  ·  15Comments

lz1988 picture lz1988  ·  32Comments

feige84 picture feige84  ·  19Comments

melihmucuk picture melihmucuk  ·  20Comments