Day 9 - ORM comparison in Go using MySql, today gorm

Today I tested gorm, which looked very promising at the first glance: You can create indexes from field tags which is not possible in gorp currently.

type TestDatabaseTableStruct struct { 

    ID   int

    Name string `sql:"index:idx_name_code"` // Create index with name, and will create combined index if find other fields defined same name

    Code string `sql:"index:idx_name_code"` // `unique_index` also works

}

But then I started to implement my simple "insert a post into one table" example where the pain started:

The interface style of gorm feels very strange, even for me, coming from a C/C++ and Delphi background. This style is all over the place, calling a method on a DB pointer and getting back a DB pointer ?!?

func (s *DB) Where(query interface{}, args ...interface{}) *DB {
    return s.clone().search.Where(query, args...).db
} 

I dont get it, maybe some people smarter than me can understand this.
I assume this strange interface of gorm is because of the "chainability" of it.

But i dont need chainability, because I am able to write SQL!

I struggled for 5 hours to make a simple "insert or update if exists" logic to get to work. I have given up! Gorm does so much annoying magic, like changing table and field names, its just too much hassle to learn another ORM layer when you would be better off learning SQL.

Im not even posting snippets, because I am so annoyed, the incomplete test source for gorm ist at gorm example .

My conclusion is: If you cant or dont want to write SQL you "could" use gorm, for everybody else use gorp.