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.
