Go type system makes generalization impossible if you also need type
safety. Not only ORM are complicated but the fact that Go lacks generic
programming features makes a Go ORM API even more horrible to use, so I'm
not surprised at all there is no appealing ORM for Go.
People suggest code generation, but it's not going to solve your problem.
Each time the database or your code is updated one or the other has to
update one or the other as well.
Ultimately even if you stick to SQL you are just also writing your own ORM
, you just can't generalize code because of Go type system. So there is no
perfect choice here.
Le mardi 27 décembre 2016 23:00:05 UTC+1, Zippoxer a écrit :
>
> 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.
