I've come to the conclusion --- maybe wrong? --- that Go doesn't want you to do ORM this way. For awhile I thought Go didn't want you to do ORM at all (which would be problematic for me, because I think writing SQL is a huge waste of time). But now I think it just doesn't want you to use ORMs that look like Django or ActiveRecord.
Instead of defining and marking up structs and setting up hooks and configuring registries of objects and stuff, just give up on dynamic ORM and switch to codegen.
I wrote a codegen ORM in a weekend that turned out much more pleasant to use than anything like gorm, not least because everything was just plain-ol'-Golang-code. All I really needed to write was the minimal Go code to dump a schema from Postgres, and then a bunch of text/template templates for all the functions I wanted. I got associations in just a couple functions.
I would have published, but it looks like 100 people had this thought before I did. sqlboiler seems like the most mature (I didn't look that carefully). But you could seriously just write your own. If I had to do it again, I'd probably codegen something on top of Squirrel.
Instead of defining and marking up structs and setting up hooks and configuring registries of objects and stuff, just give up on dynamic ORM and switch to codegen.
I wrote a codegen ORM in a weekend that turned out much more pleasant to use than anything like gorm, not least because everything was just plain-ol'-Golang-code. All I really needed to write was the minimal Go code to dump a schema from Postgres, and then a bunch of text/template templates for all the functions I wanted. I got associations in just a couple functions.
I would have published, but it looks like 100 people had this thought before I did. sqlboiler seems like the most mature (I didn't look that carefully). But you could seriously just write your own. If I had to do it again, I'd probably codegen something on top of Squirrel.