I've used naked SQL, and ORMs (Django in Python, Hibernate and EBean in Java, GORM in Go) for years, and I've noticed the following:
1) It's really easy to write very inefficient queries in an ORM. If you have a very simple 1:1 mapping between tables and objects, it's fast, efficient, easy to use, and by all means, use the ORM. However, once you start doing tricker things, like references to other objects (aka, foreign row constraints on other tables), or array type fields, things get really tricky. 2) A database abstraction layer is nice, because while SQL is standard, every dang database extends SQL in its own way that's usually not compatible with others. For example, Postgres supports array columns. MySQL does not. These two are both very popular. If you have an object which you're storing in a table, your approach in each DB will be drastically different. In Postgres, you just write the array into a column. In MySQL, you have to decompose to First Normal Form, meaning you create a table for the array column, and have some sort of array/table -> PK mapping. Or, you give up on any kind of easy array searching, and just marshal your array to JSON or whatever, and throw it in a CLOB. 3) An ORM ties your hands to using SQL in whatever approach it presents, so you frequently do naked SQL outside of the ORM, particularly if you want to use something to speed up a query which is very difficult for an ORM to express, such as Window Functions in Postgres. Given that no two SQL engines speak the same dialect, and ORMs don't understand intent, you're basically always debugging. If your object model is simple, an ORM saves work, if it's complex, I'd argue it's more work. If you have to support multiple DB's, eg, Postgres for production. SQLite for unit tests, you need a query builder since their syntax is incompatible, or stick to a compatible subset. SQL is a mess, ORM or no ORM, and in any language. Just use what works for you, and reevaluate if it starts to cause problems. I've been responsible for internet facing services backed by databases for quite a few years now, could rant about this for a long time. My current system, and the best one yet, having learned from past mistakes, uses something like Liquibase for schema management (I wrote it in Go, I'll be open sourcing it at some point, once it's battle hardened), and naked SQL queries, with some simple wrappers to hide nullable columns, since the zerovalue in go is simpler to work with than optionals. -- Marcin On Sat, Sep 28, 2019 at 6:12 PM Robert Engels <reng...@ix.netcom.com> wrote: > ORM is object relational mapping. Go is only pseudo object oriented. I > will say again that complex object graphs and persistence is very hard > without an ORM or a LOT of custom code. > > Since Go does not have runtime compilation a true (or easy anyway) ORM in > Go requires code generation. > > On Sep 28, 2019, at 9:32 AM, Rodolfo <rof20...@gmail.com> wrote: > > "First, nobody thinks that knowing ORM's query language absolves one from > knowing SQL." > > Speak for yourself. > > If you a hard spring boot user you can get into this problem. > > Example: > > findAll = select * from entity > > This is have nothing with SQL. > > findAllBySomeProperty = select * from entity where property = ? > > This is have nothing with SQL. > > Please, do not be rude, be honest. > > Em sáb, 28 de set de 2019 00:49, <alex.besogo...@gmail.com> escreveu: > >> First, nobody thinks that knowing ORM's query language absolves one from >> knowing SQL. >> >> But the main issue is that Go SQL interface SUCKS. It's verbose, hard to >> use and is difficult to integrate with additional tooling (try adding >> generic tracing support, I dare you!). So often your SQL code is hidden in >> reams of wrapper code that sets arguments and reads the results. >> >> So even simple ORMs that allow mapping of result sets to objects help to >> reduce boilerplate clutter. More advanced ORMs also offer simple type safe >> queries: https://github.com/go-reform/reform >> >> It's still nowhere close to LINQ for C# or http://www.querydsl.com/ for >> Java, but it's getting there. >> >> On Friday, September 27, 2019 at 3:34:59 AM UTC-7, Dimas Prawira wrote: >>> >>> Many Gophers don't like ORM as : >>> 1. ORM introduce an additional layer of abstraction that doesn't >>> accomplish anything. >>> 2. SQL syntax is more or less the same for every database. >>> 3. If you learn an ORM in Java, you will only ever able to use that ORM >>> knowledge in Java. If you learn SQL, you can use that SQL with almost >>> _exactly the same_ with any other database, and in any programming language. >>> 4. ORMs don't save you any time. The number of "lines" of code for an >>> ORM will be more or less the same as the equivalent logic done in SQL. >>> >>> But if still need to use ORM for any reasons, then you can try GORM >>> https://gorm.io/ >>> >>> cheers >>> >>> On Fri, Sep 27, 2019 at 4:20 AM b ram <bram.go...@gmail.com> wrote: >>> >>>> Hi, >>>> >>>> Can you pls suggest libs for ORM & Schema Migration. >>>> >>>> Thanks. >>>> >>>> -- >>>> 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 golan...@googlegroups.com. >>>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/golang-nuts/CAB9V516cRxPc8xuQcXQyBGXZWenv0o9ned%2BFDq2WmXyhBNm2Sg%40mail.gmail.com >>>> <https://groups.google.com/d/msgid/golang-nuts/CAB9V516cRxPc8xuQcXQyBGXZWenv0o9ned%2BFDq2WmXyhBNm2Sg%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>> -- >> 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. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/golang-nuts/92a68ef4-9836-4d1a-8bb5-a73f0ab1d7b8%40googlegroups.com >> <https://groups.google.com/d/msgid/golang-nuts/92a68ef4-9836-4d1a-8bb5-a73f0ab1d7b8%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- > 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. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/CABjW-rxMuCSqfk-riHw3Mt_rP9R2gdK3WcooL_aHh3t5YeDCXA%40mail.gmail.com > <https://groups.google.com/d/msgid/golang-nuts/CABjW-rxMuCSqfk-riHw3Mt_rP9R2gdK3WcooL_aHh3t5YeDCXA%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > -- > 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. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/6763BAB4-FE01-45EB-947D-839E853BD9E2%40ix.netcom.com > <https://groups.google.com/d/msgid/golang-nuts/6763BAB4-FE01-45EB-947D-839E853BD9E2%40ix.netcom.com?utm_medium=email&utm_source=footer> > . > -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CA%2Bv29LvHb5Y1e-oQrO6jNDo4wMGr5%2BM%2BYrWpY6Re3wY47mThcg%40mail.gmail.com.
