On Friday, December 30, 2016 at 7:43:13 PM UTC+7, parais...@gmail.com wrote: > > 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. > > Every time there is a change in the database (eg. adding a column to your table), you still need to make a corresponding change to your code. There is no other way around it. No generics or ORM can help you there. However, changes in code do not always lead to a change in the database. Data structures may be represented differently in the database. Your code is dependent on the database, but not vice versa.
If you use ORM, you assume there is a 1 on 1 mapping between your data structure and its representation in the database. This makes your database structure highly coupled to your code. Hence, I think it is a bad design. Your database schema must be as stable as possible with fewer possible alteration in the future. It's how you map your data that matters. With ORM, you lose that flexibility. Btw, generics is actually code generation. -- 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.
