[masklinn]

That's more of a query builder than an ORM: it doesn't actually use objects and only allows for expressing SQL queries in Go.

In that it is similar to LINQ or HQL or SQLAlchemy Core — at an even lower level really since things like conditions are provided as parameterised strings.

[samonzeweb]

I agree, it’s a simple tool. As mentioned in the README, it’s not a full-featured ORM, but it does more than building queries as it maps Go structs with databases content (on this point I disagree as it use objects).

The purpose is to be more productive than doing all this job manually.

Many things can be improved, it's sill a young project. This project is initially a learning one : doing stuff to improve my skill, on my spare time. I tried to build something clean, and used it on some real data. Perhaps it could be useful for somebody else. Nothing more ;)

[masklinn]

> on this point I disagree as it use objects

That's a technicality, it just loads query data into objects which is what more or less every query builder does, the objects aren't involved in any of the logic. By the benchmark you use psycopg is an ORM (it really isn't, it isn't even a query builder).

Don't misunderstand, I'm not saying a query builder is bad, I'm just saying this is not an ORM, and shouldn't be sold as such: it's going to disappoint people looking for ORMs like Django's or Rails's and it's going to turn off people who object to ORMs[0] but would have been interested in a query builder.

Not to mention a good query builder is an excellent basis for a full-fledged ORM.

[0] and there are many people who think ORMs are a terrible idea

[eternalban]

> there are many people who think ORMs are a terrible idea

Not sure about terrible but it is not a bright idea to be object centric when schema remains king. Using ORMs makes perfect sense when your domain model is canonically represented by the object tier /and/ you are reusing these (common/core) domain objects to build a multiplicity of applications.

[samonzeweb]

We agree. In fact I did not know how to qualify * exactly * godb.

[weberc2]

> it just loads query data into objects which is what more or less every query builder does

Query builders build queries (like SQLAlechemy's core library). ORMs know how to marshal object attributes to/from database columns. None of this is to say that one is better than the other.

[edoceo]

I don't like ORM in specific cases. Was looking for a query builder and almost ignored this post cause I don't need yet another ORM. Agree with rebranding as a QB, unless project intents to become ORM in the larger sense

[Hannan]

>> [0] and there are many people who think ORMs are a terrible idea

Do you have any links perchance? Because I can't shake the feeling that I'm a pariah among the developer community for thinking this way.

[sarabob]

https://blog.codinghorror.com/object-relational-mapping-is-t... for example :-)

[Hannan]

Excellent, thank you!

[SanFranManDan]

Agreed.

In the functional world, there obviously aren't objects and structs are not the same things as objects in the OOP sense.

Even then the key part of a ORM is the "R". ORMs allow you to utilize a RDBMS transparently as if you were manipulating the OOP objects.

A couple of projects that this is closer to than Django ORM.

https://github.com/elixir-ecto/ecto -> "Database Wrapper" http://www.yesodweb.com/book/persistent -> "data store interface" https://hackage.haskell.org/package/groundhog -> "Database Mapping"

[chisleu]

When your structs can have functions on them that modify the original struct's data, the line between object and "really really object like struct" is very thin.

I appreciate this guy's work, but DSLs make more sense to me than orms in golang.