Re: [go-nuts] Golang library for - ORM & Schema Migration

[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

-- 
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/ee783450-0354-41d7-8d7f-67c0498cf9c1%40www.fastmail.com.

Re: [go-nuts] Golang library for - ORM & Schema Migration

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

-- 
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/f3abdba2-7e2b-4bdb-9054-b9694eb48445%40www.fastmail.com.

Re: [go-nuts] Golang library for - ORM & Schema Migration

[bram]

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

Re: [go-nuts] Golang library for - ORM & Schema Migration

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

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

Re: [go-nuts] Golang library for - ORM & Schema Migration

[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



On Sat, Sep 28, 2019 at 6:12 PM Robert Engels  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  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,  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  wrote:
>>>
 Hi,

 Can you pls suggest libs for  ORM & Schema Migration.

 Thanks.

Re: [go-nuts] Golang library for - ORM & Schema Migration

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

> On Sep 28, 2019, at 9:32 AM, Rodolfo  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,  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  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.
>> 
>> -- 
>> 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.
> 
> -- 
> 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.

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

Re: [go-nuts] Golang library for - ORM & Schema Migration

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

Em sáb, 28 de set de 2019 00:49,  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  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
>>> 
>>> .
>>>
>> --
> 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
> 
> .
>

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

Re: [go-nuts] Golang library for - ORM & Schema Migration

[Dimas Prawira]

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

cheers

On Sat, Sep 28, 2019 at 8:03 PM Lutz Horn  wrote:

> alex.besogo...@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/
>
> --
> 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/0aab4dd2-374b-1915-b6f7-77089c42733f%40posteo.de
> .
>

-- 
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%2Bp%2BMUc_7GrbtKtvnG%3D%2BXhqQA0GSF0B6_9oJm7WN9iNR7vkX4w%40mail.gmail.com.

Re: [go-nuts] Golang library for - ORM & Schema Migration

[Dimas Prawira]

Let me answer that with code

 ORM syntax
db.Where("name = ?", "donald").First()

another ORM syntax

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

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








On Sat, Sep 28, 2019, 11:50 AM  wrote:

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

-- 
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%2Bp%2BMUeX8aAo6eOxT_fWq%3DuB3Aa8vgRTH7t36ZuK6D1DFdj9yw%40mail.gmail.com.

Re: [go-nuts] Golang library for - ORM & Schema Migration

[Lutz Horn]

alex.besogo...@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/

--
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/0aab4dd2-374b-1915-b6f7-77089c42733f%40posteo.de.

Re: [go-nuts] Golang library for - ORM & Schema Migration

[Space A.]

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



On Saturday, September 28, 2019 at 7:50:22 AM UTC+3, alex.b...@gmail.com 
wrote:
>
> 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  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
>>>  
>>> 
>>> .
>>>
>>

-- 
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/537ad21d-4f85-4a23-bf45-89a647ac527a%40googlegroups.com.

Re: [go-nuts] Golang library for - ORM & Schema Migration

[alex . besogonov]

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

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

Re: [go-nuts] Golang library for - ORM & Schema Migration

[Robert Engels]

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

> On Sep 27, 2019, at 1:27 PM, Robert Engels  wrote:
> 
> 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. 
> 
>>> On Sep 27, 2019, at 7:05 AM, Lutz Horn  wrote:
>>> 
>>> 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
>> 
>> -- 
>> 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/20190927120547.GA4127%40pc-lutz.ecm4u.intra.
> 
> -- 
> 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/D5892013-0777-49E2-AC31-0A643D8D0A8D%40ix.netcom.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 golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/9B1893DF-FF7A-42E0-AF6C-0820AA415987%40ix.netcom.com.

Re: [go-nuts] Golang library for - ORM & Schema Migration

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

> On Sep 27, 2019, at 7:05 AM, Lutz Horn  wrote:
> 
>> 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
> 
> -- 
> 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/20190927120547.GA4127%40pc-lutz.ecm4u.intra.

-- 
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/D5892013-0777-49E2-AC31-0A643D8D0A8D%40ix.netcom.com.

Re: [go-nuts] Golang library for - ORM & Schema Migration

[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

-- 
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/20190927120547.GA4127%40pc-lutz.ecm4u.intra.

Re: [go-nuts] Golang library for - ORM & Schema Migration

[Josh Kamau]

This works well for me.
https://upper.io/db.v3/

On Fri, 27 Sep 2019 at 15:56, Robert Engels  wrote:

> 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.
>
> On Sep 27, 2019, at 6:13 AM, Dimas Prawira 
> wrote:
>
> 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(); err != nil {
>   return 0, err
>   }
>   return id, nil
>   }
>
> queries are just as simple.
>
> --
> 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%2Bp%2BMUebx-LZ%2Bj9qTvoDJrL7RCyBrNJ5P6nq0M8YPs3wh_HCEQ%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 golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/1DCC8F36-9213-42E7-A156-273A93429686%40ix.netcom.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 golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CALHF5toPy%2Bfn_d2YNP2unVF277wkp0c7pYPjm-nXRku8RrHLFQ%40mail.gmail.com.

Re: [go-nuts] Golang library for - ORM & Schema Migration

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

> On Sep 27, 2019, at 6:13 AM, Dimas Prawira  
> wrote:
> 
> 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(); 
> err != nil {
>   return 0, err
>   }
>   return id, nil
>   }
> 
> queries are just as simple.
> -- 
> 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%2Bp%2BMUebx-LZ%2Bj9qTvoDJrL7RCyBrNJ5P6nq0M8YPs3wh_HCEQ%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 golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/1DCC8F36-9213-42E7-A156-273A93429686%40ix.netcom.com.

Re: [go-nuts] Golang library for - ORM & Schema Migration

[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(); err != nil {
  return 0, err
  }
  return id, nil
  }

queries are just as simple.

-- 
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%2Bp%2BMUebx-LZ%2Bj9qTvoDJrL7RCyBrNJ5P6nq0M8YPs3wh_HCEQ%40mail.gmail.com.

Re: [go-nuts] Golang library for - ORM & Schema Migration

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

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

-- 
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/CADKwOTcM6XK%3Dzzc2_4fBAUc2Uunby3AR%2BZgTHtc%3DjU-S74%3D9Wg%40mail.gmail.com.

Re: [go-nuts] Golang library for - ORM & Schema Migration

[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

On Fri, Sep 27, 2019 at 4:20 AM b ram  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 golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/CAB9V516cRxPc8xuQcXQyBGXZWenv0o9ned%2BFDq2WmXyhBNm2Sg%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 golang-nuts+unsubscr...@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.