Hi, When I gave some thought to the whole ORM, I concluded it was not the SQL that bothered me it was these items
1. Adding a new column to table means having to revisit every query/insert/update that could be affected 2. Serializing and de-serializing as things get saved/read from DB (dealing with null values, date time conversions, blobs that should be parsed into e.g. json etc.) So rather than create some magical layer above SQL I simply attempted to abstract the above items into one place. So that when adding a new column one only has to adjust the serializer and de-serializer methods, and when querying one simply omits listing the columns. Here my attempt at the above - https://github.com/jlabath/dbi Cheers Jakub Labath On Tuesday, December 27, 2016 at 10:00:05 PM UTC, Zippoxer wrote: > > 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.
