The following "ORM's" i did not actually test, just googled it. Maybe the info is usable for somebody.
StarDate is 2015.05.18
beedb :although beedb has been called dead and unmaintained, it seems to be still alive as a sub of beego: beego orm. But as it is part of a larger framework I have pushed it back in my queue.
qbs: This looks to me like an awesome lib and it is for sure worth further examining: It can create Indexes and does so even on joined/embedded structs. Note to myself: Do a separate post on qbs!
My progress in learning the programming language Go from Google in the form of a daily blog
Showing posts with label orm. Show all posts
Showing posts with label orm. Show all posts
Monday, May 18, 2015
Friday, May 15, 2015
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.
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 ?!?
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.
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.
Subscribe to:
Posts (Atom)