Golang library for - ORM & Schema Migration

[b ram]

Hi,

Can you pls suggest libs for  ORM & Schema Migration.

Thanks.

[Space A.]

gorm.io

[Dimas Prawira]

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

--
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...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAB9V516cRxPc8xuQcXQyBGXZWenv0o9ned%2BFDq2WmXyhBNm2Sg%40mail.gmail.com.

[Space A.]

Many gophers like ORM.

ORM is a tool and as any other tool it does save the time when used in a right way in a right place. But you need to learn how to use it.

пт, 27 сент. 2019 г. в 13:35, Dimas Prawira <prawira.d...@gmail.com>:

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 golang-nuts...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CA%2Bp%2BMUeNpeCo_RRfb%2BQRVK%3DHHNhfY4_WYo12QeV8AQOfG%2B2KvA%40mail.gmail.com.

[Dimas Prawira]

if there's something you _don't_ know how to do in SQL, and it seems the ORM can do it for you, capture the raw SQL the ORM produces
and tell me if it's easier for you to understand the SQL or the random ORM API. I 100% guarantee you that the raw SQL the ORM produces will be easier to understand

ie: you could write the same raw SQL too, if you just tried


All i'm suggesting is: try to learn raw SQL — i think you'll be pleasantly surprised at just how flexible and easy it is
i would also argue that learning SQL is easier than learning a random ORM syntax. and raw SQL has the benefit that you'll be able to use it again, on a future project, in a different programming language
while every ORM i've ever seen is 100% bound entirely to only the programming language it's used in
i've never seen two ORMs with the same API, or even a similar API
but raw SQL stays the same, for now and 50+ years from now

Let me give you an example :

// newSession creates a new session in the database, returning the created    
  // session id.    
  func (s *server) newSession(remoteAddr string) (int64, error) {    
      const sqlstr = `insert into sessions (remote_addr) values ($1) returning session_id`    
      var id int64    
      if err := s.db.QueryRow(sqlstr, cleanRemoteAddr(remoteAddr)).Scan(&id); err != nil {    
          return 0, err    
      }    
      return id, nil    
  }

queries are just as simple.

[Robert Engels]

The piece you are missing about ORM is the automatic change detection and caching when using complex object graphs. This is not trivial by any means when using raw SQL. It’s not easy using an orm either sometimes - depends on the orm. 

--

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...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CA%2Bp%2BMUebx-LZ%2Bj9qTvoDJrL7RCyBrNJ5P6nq0M8YPs3wh_HCEQ%40mail.gmail.com.

[Josh Kamau]

This works well for me. 

https://upper.io/db.v3/

To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/1DCC8F36-9213-42E7-A156-273A93429686%40ix.netcom.com.

[Lutz Horn]

On Fri, Sep 27, 2019 at 05:34:28PM +0700, Dimas Prawira wrote:
> Many Gophers don't like ORM as :

Just to emphasize this point:

https://korban.net/posts/postgres/2017-11-02-the-case-against-orms/

Lutz

[Robert Engels]

And I’ll reiterate that you’re (and the article) is missing the point.

Using a simple case of customers and orders. With an ORM when you want to show all orders for all customers with the customer details, you need to join the customer with the order in every row. This is a huge waste of bandwidth (although many advanced db drivers won’t ship the redundant customer info over the network).

So either you use an ORM or you roll your own (using maps and lookups).

And this is just a trivial 2 table join.

> --
> 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...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/20190927120547.GA4127%40pc-lutz.ecm4u.intra.

[Robert Engels]

It was supposed to be “without an ORM”...

> To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/D5892013-0777-49E2-AC31-0A643D8D0A8D%40ix.netcom.com.

[alex.be...@gmail.com]

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.

[Space A.]

Absolutely, plus ORM usually offers a convenient way to run raw SQL queries, if you need it.

[Lutz Horn]

alex.be...@gmail.com:

> 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.

That's true. In the Java world, few people use the JDBC API directly,
which has similar flaws. But this does not mean that JPA and Hibernate
have to be used. Libraries like JDBI[1] exist that provide a much more
usable API without the necessities of the ORM concept.

Ragarding the "migration" part of the question, in the Java world
libraries like Flyway[2] allow fine grained control of schema migrations.

For both use cases similar libraires surely exist for Go. But maybe the
question was about migrating ORM code and the DB schema together. I am
not aware of any solution that does this.

Lutz

[1] http://jdbi.org/
[2] https://flywaydb.org/

[Dimas Prawira]

Let me answer that with code 

 ORM syntax 

db.Where("name = ?", "donald").First(&user)

another ORM syntax

err := o.QueryTable("user").Filter("name", "slene").One(&user)

another ORM syntax

findByUserdAndOrderCreatedAtBetween(String ovoId, Date startDate, Date endDate, Pageable pgRequest)

does you know what exactly going on with those query if not show the Raw query with debug ?

most developers don't really care about SQL, because the important thing is the results come out as desired. But I suggest you should https://github.com/jinzhu/gorm/issues/2517

if you don't like SQL on stdlib, I can suggest using https://github.com/xo/xo

and using raw SQL in ORM for me like wasting time.

cheers

To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@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.

[Dimas Prawira]

migrations should not be _rarely_ if you are writing migration scripts often, that's a big big big big different problem

cheers

--
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...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/0aab4dd2-374b-1915-b6f7-77089c42733f%40posteo.de.

[Rodolfo]

"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.

To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@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.

[Robert Engels]

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. 

To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CABjW-rxMuCSqfk-riHw3Mt_rP9R2gdK3WcooL_aHh3t5YeDCXA%40mail.gmail.com.

[Marcin Romaszewicz]

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

To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/6763BAB4-FE01-45EB-947D-839E853BD9E2%40ix.netcom.com.

[Space A.]

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>:

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 golang-nuts...@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.

[bram]

Thank you all.  For schema migration i am looking for similar tool like flyway.

, 

Regards,

Bram.

To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/92a68ef4-9836-4d1a-8bb5-a73f0ab1d7b8%40googlegroups.com.

--
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/CABjW-rxMuCSqfk-riHw3Mt_rP9R2gdK3WcooL_aHh3t5YeDCXA%40mail.gmail.com.

--
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/6763BAB4-FE01-45EB-947D-839E853BD9E2%40ix.netcom.com.

--
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CA%2Bv29LvHb5Y1e-oQrO6jNDo4wMGr5%2BM%2BYrWpY6Re3wY47mThcg%40mail.gmail.com.

[Andrew Pillar]

I created a simple migration tool called mgrt [1], which operates on pure SQL
scripts that are defined by the user. It has support for MySQL, SQLite and
PostgreSQL. Give it a try if you're looking for a simple migration tool that
just uses plain SQL under the hood. It's written in Go, so building it won't be
too hard.

[1] - https://github.com/andrewpillar/mgrt

Accidentally replied to the wrong thread on the list with this :/

[Sam Whited]

On Mon, Sep 30, 2019, at 21:05, bram wrote:
> Thank you all. For schema migration i am looking for similar tool
> like flyway.

I'm not sure if it's like flyway, but I use a library that I wrote,
code.soquee.net/migration [1]. The idea is that it gives you the tools
you need to write a migration command instead of being a separate
migration tool, this way your application can handle its own migrations
(this makes it really easy to distribute your application to customers
if you have an on-premis version that their ops people will need to run
migrations on). It is designed to run migrations from a folder or
embedded filesystem (eg. using statik [2] or pkgzip [3]). Currently it
is compatible with Diesel and supports PostgreSQL, but it could likely
be made to support whatever you're using easily enough.

—Sam

[1]: https://godoc.org/code.soquee.net/migration
[2]: https://godoc.org/github.com/rakyll/statik
[3]: https://godoc.org/code.soquee.net/pkgzip