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.
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 ;)
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
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.
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.
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.
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"
I appreciate this guy's work, but DSLs make more sense to me than orms in golang.