Wow. the amazing amount of projects mentioned in this thread are interesting. Surprised that by now there isn't a well established leader or leaders for such a common need.
On Sunday, September 10, 2017 at 10:01:51 AM UTC+12, Denis Isaev wrote: > > Take a look at kallax <https://github.com/src-d/go-kallax> and queryset > <https://github.com/jirfag/go-queryset>. They are modern typesafe ORMs, > allowing to write safe and reusable code. > > среда, 28 декабря 2016 г., 1:00:05 UTC+3 пользователь Zippoxer написал: >> >> I haven't written SQL for years. I was enjoying MongoDB with the awesome >> mgo package, and what saved me a lot of headache was the natural >> programmatic interface of MongoDB. >> mgo maps your data (structs, maps, slices) to MongoDB queries and from >> MongoDB results, and you can write any MongoDB query possible with the >> mgo/bson package exclusively. >> >> I've seen the sqlx package which only does mapping of results from the >> database, but not the other way around -- so you still have to type some >> queries like this: >> func InsertFoo(v Foo) { >> db.Exec(`INSERT INTO x (bla, bla2, bla3, bla4, bla5, bla6, ...) >> VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ...)`, v.bla, v.bla2, v.bla3, >> v.bla4, v.bla5, v.bla6, ...)} >> } >> >> I can live with this verbosity, but that's not my problem. What happens >> when you add a field to the struct *Foo*? You have to modify the query >> above in three places and make sure you typed every character correctly. >> And there are probably more queries updating *Foo*. Seems like too much >> manual maintenance to do -- and I believe this increases the chance of bugs. >> >> A classic solution to this problem would be to use an ORM. I've looked at >> SQLBoiler <https://github.com/vattle/sqlboiler> and I'm very excited to >> see an ORM that generates Go code instead of using reflection. However, it >> still has the classic problem of ORMs that we all discuss from time to time. >> Like any ORM, due to it being an additional layer on top of the database, >> it adds complexity (instead of verbosity and the manual query maintenance >> above) and you might have to write raw SQL anyway (what if you only want to >> select 2 fields of Foo instead of all of them? what about complex queries?) >> >> Considering all that, I still cannot reach a conclusion. I'm going back >> and forth on that issue. >> >> Since I appreciate the opinions of this community more than any other >> community I know right now, can you guys pour your opinions on the matter? >> > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
