Re: [go-nuts] Do you guys use ORMs when working with SQL?
On Dec 30, 2016, at 4:43 AM, paraiso.m...@gmail.com wrote: > > 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. There are really two separate (but related) issues in the ORM debate: the ORM design pattern, and ORM libraries. By “the ORM design pattern,” I mean the concept that there should be a direct mapping between the objects in your program and the tables in your database. In other words, that each table in the database should correspond to a type or class, and that each row of that table corresponds (at least potentially) to an instance of that type. ORM libraries, of course, are abstractions created to make it easier to write code that follows the ORM design pattern. Many people seem to take the ORM design pattern for granted, and just debate whether it’s better to do the mapping manually or to use an ORM library. But I am skeptical of the design pattern itself. I seldom create a type that corresponds exactly to one of my database tables. Most often I use a struct or slice of structs that corresponds to the data I want from a particular database query; usually it is an anonymous type, declared directly in my HTTP handler function. Then I have some helper functions (most notably one called queryInto) that fill in the data with the results of the query. Andy -- 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.
[go-nuts] Do you guys use ORMs when working with SQL?
I use plain SQL. Since I deal with mostly financial data, I need to control how my data get changed. I don't want some ORMs doing some funky business which may inadvertently lead to data corruption. I usually write a mapper for every table in the database. If a table structure is changed, I just fix the corresponding mapper. The rest of the code does not need to know SQL. I have been thinking of auto generating these mappers using go generate, but hmm.. maybe next year. -- 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.
[go-nuts] Do you guys use ORMs when working with SQL?
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 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.
