knex violates promises contract on del()

Hey

I think I found a pretty nasty bug regarding promises changing its value when using del(). I am not sure if other operations (like update) and/or other database engines are affected, but for sure this problem on Postgre kiasaki/alpine-postgres and knex v0.12.7.

The problem is: 1 insert a singe row to db: db('documents').insert({customer_number:1, contract_number:'b',document_number:222,contract_number_prefix:'ab'}).then(console.log) 2. Delete via del() var res = db('documents').del(); 3. resolve returned promise more than once: res.then(console.log) returns 1 (OK) res.then(console.log) returns 0 (Incorrect) res.then(console.log) returns 0 (Incorrect) res.then(console.log) returns 0 (Incorrect)

Why a subsequent resolving promise returns different value - first 1 and then 0 ?

[elhigu]

@jmilkiewicz I’m not claiming that del() returns promise. It returns QueryBuilder which is thenable.

If documentation says that some of the QueryBuilder methods are returning Promise the documentation is wrong (I didn’t find anything that claims QueryBuilder being Promise, but it has an API to interact with Promises).

// instance of QueryBuilder
let queryThenable = knex('foo').del(); 

// instance of Promise (bluebird promise actually)
let resultPromise = queryThenable.then(res => res); // res == 1 (one row in the table)

// through the promise result won't change and query won't be triggered again
resultPromise.then(res => console.log("res is still 1:", res));

// through the thenable query is triggered again
queryThenable.then(res => console.log("res should be now 0:", res));

Edit: fixed variable names

[jmilkiewicz]

thx for information. If i were to design it i would make a queryBuilder immutable. It would allow one to use chain methods for where, group, sort, projection and so on. The queryBuilder would have 3 “termination” methods (probably with arity 0): select, delete, update. All of them would execute the query and return a promise (as queryBuilder is immutable - they will never mutate it). So if one would like to reuse a particular query, would need ti store queryBuilder and simple call one of terminating methods to re-execute.

You are right that in most cases you will map result of your query in then, but my query was simply a “delete”, so there is nothing to map…