Thank you all. For schema migration i am looking for similar tool like flyway. , Regards, Bram.
On Sunday, September 29, 2019 at 2:34:55 AM UTC-7, Space A. wrote: > > ORM is a tool. It's not good or bad. Every tool, every language and > everything has limits. If you like spending time on writing and debugging > raw SQL - go ahead. The difference and very obvious in this discussion, is > that those who are not against ORM not trying to convince other party to > only use this and that and nothing else. > > > вс, 29 сент. 2019 г. в 05:19, Marcin Romaszewicz <mar...@gmail.com > <javascript:>>: > >> >> 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 <ren...@ix.netcom.com >> <javascript:>> 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 <rof2...@gmail.com <javascript:>> >>> 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.b...@gmail.com <javascript:>> >>> 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 golan...@googlegroups.com <javascript:>. >>>> 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 golan...@googlegroups.com <javascript:>. >>> 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 golan...@googlegroups.com <javascript:>. >>> 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 a topic in the >> Google Groups "golang-nuts" group. >> To unsubscribe from this topic, visit >> https://groups.google.com/d/topic/golang-nuts/m-h6sDAX_MA/unsubscribe. >> To unsubscribe from this group and all its topics, send an email to >> golan...@googlegroups.com <javascript:>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/golang-nuts/CA%2Bv29LvHb5Y1e-oQrO6jNDo4wMGr5%2BM%2BYrWpY6Re3wY47mThcg%40mail.gmail.com >> >> <https://groups.google.com/d/msgid/golang-nuts/CA%2Bv29LvHb5Y1e-oQrO6jNDo4wMGr5%2BM%2BYrWpY6Re3wY47mThcg%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/c742c8fa-7b1a-4fa8-9949-6f35b26934dd%40googlegroups.com.
