Question

[vitaly-t]

In your example you show how to swap query formatting in pg-promise to your library.

pg-promise has a very rich query formatting syntax, which includes:

• named parameters with self-reference (this);
• raw-text formatting;
• custom-type formatting.

Your library doesn't yet have any of those features. But that is secondary. More important is the following...

There are 3 types of database frameworks:

• low-level / drivers, based on callbacks, mostly;
• promise-based constructs on top of drivers
• ORM-s

pg-promise, for one, is a promise library built on top of a driver, it is absolutely not an ORM. When people want an ORM instead, they go for something else, like knex.js, sails.js or sequelize.js

And your example suggests that someone would take pg-promise and try turn it into an ORM. It is confusing as to why anyone would want to do that. They would either stick with the rich text formatting features of pg-promise or go for one of the known ORM-s.

[jails]

This library is a simple SQL builder. It only provides an API to create SQL strings instead of dealing with plain SQL strings directly. Then you can use the driver you want to exectute the generated SQL (i.e pg-promise, pg, mysql or even sqlite) whatever is fine as long as the driver is able to exectute some SQL. So this library is not intended to be an ORM but to be used as an SQL abstract layer by an ORM. Btw the ORM will come soon ;-)

[vitaly-t]

I guess we target two groups of developers on the opposite sides:

• those who love writing stuff using native SQL queries, people with good database background;
• those who are not familiar with database syntax and prefer an abstraction layer instead.

There is no point arguing one over the other, it boils down to personal experience and preferences.

I myself was planning to yank the query-formatting part of pg-promise and publish it as a separate library, which still may happen :)

Keep up good work! :+1: