[Feature Request] end event for Pool

Client do have "end" event, but according to the documentation currently Pool does not have "end" event. It would be nice to have the "end" event for the Pool as well.

[charmander]

What would you use it for, compared to the pool.end() callback/promise?

In general it might be useful for the scenario where pool is created in one place, but pool.end() is used in several places (of course only one of them might be actually called during runtime, but in the code pool.end() might be written in many places nevertheless, and existence of the "end" event for the pool would considerably simplify this scenario by allowing to simply attach that "after the end/whatever" code via pool.on("end", ()=>{whatever}); right after the creation of the pool, at the single place where the pool is created, instead of attaching pool.end() callbacks everywhere). It would allow to have a slightly cleaner code and avoid the repetitive "handle the pool.end()" callbacks.`

[vitaly-t]

@tvibliani

I don't see much value in it either.

But if you need it, then just add it on your side:

function addEndEvent(pool) {
    if (pool.ended || pool.ending) {
        return;
    }
    const oldEnd = pool.end;
    pool.end = function (cb) {
        const res = oldEnd(cb);
        pool.emit('end');
        return res;
    }
}

Then you can call addEndEvent on the pool when you create it, and it will support end event.

[charmander]

pool.end() is used in several places

I feel like that’s not usually a good idea, and that most cleanup shouldn’t be tied to a pool ending (unless you were just going to use the event for logging).

@charmander using pool.end() in several places is totally valid use case, starting from implementation of "clean shutdown" of production/development versions under various circumstances and ending by dropping temporary databases used for testing. I can think of some more use cases in between of those mentioned here and logging is the last thing. Can you elaborate what makes you feel like it is a bad idea to use pool.end() in several places in code? For example if tests are successful I want to drop the temporary test database used in tests, and this should be tied exactly to the pool ending, there is no better timing or better place for dropping database, in many cases database cannot be dropped unless pool is ended, dropping early might throw an error. But at the other hand, if some tests fail I might prefer to keep the database instead of dropping, perhaps for further investigation of failed cases. etc. All in all in development/production code it might be needed in several different places, of course with as much DRY in mind as possible, but anyway.

Coming back to the "events" currently used in this library, we have the following situation:

• Current list of Client events:

  • 'end'
  • 'error'
  • 'notice'
  • 'notification'

• Current list of Pool events:

  • 'acquire'
  • 'connect'
  • 'error'
  • 'remove'

As we have 'end' event in the Client events it is against intuition that it is missing from Pool, I will spare you details, but other differences in the above event lists does not break my intuition, however the 'end' event missing from the Pool's event list does.