Logging

[jsumners]

It'd be really helpful if this module supported logging. In particular, it would be helpful if it accepted any log4j style compliant logger. There are a couple libraries that help with this:

• https://www.npmjs.com/package/abstract-logging
• https://www.npmjs.com/package/abslog

[cjbj]

It would be good to have some infrastructure in node-oracledb to make it easy for users to implement their own preferred logger. PRs welcome.

[jsumners]

Sorry, https://github.com/oracle/node-oracledb/blob/master/.github/pull_request_template.md prevents me from submitting a PR.

[dmcghan]

Hi @jsumners, I'm not sure we'd want to favor one API like log4j/log4js. When we added support for promises we were able to do it in a way that allowed folks to use the default or supply their own (like Bluebird). It'd be nice if we could do something like that for this too, though that may be wishful thinking.

The abstract logging utilities you pointed out don't seem to have much traction. :(

Here's a comparison of some popular libs: https://npm-stat.com/charts.html?package=bunyan&package=log4js&package=winston&from=2017-01-29&to=2018-01-29

What kinds of things are you debugging and how would logging help? I'm not saying logging will not help, I'm just looking for specifics for your situation.

Do you think integration with Async Hooks and/or Performance APIs should be considered for this?

[jsumners]

They may not have millions of downloads themselves, but the libraries they facilitate do. In fact, the ones you linked are ones that users can supply as a logger that matches the specification.

That's the point of the "abstract" (null) loggers I linked. They merely provide the API to component libraries such as oracledb so that the component library does not become encumbered with a specific logger.

One thing oracledb could log is connection attempts. I was writing an app earlier that was hanging on start and I had no visible clue why. It turned out it was this library waiting for a connect timeout. Had I been able to attach my pino instance, at debug or trace level, I would have some feedback to read.

[jsumners]

If it's not clear: using abstract-logging accomplishes exactly what you want -- allowing the user to sub in a logger to replace it. That's it's whole purpose as is described in the readme.

[dmcghan]

@jsumners Thanks for the feedback.

[anthony-tuininga]

Not to detract from the desirability of logging at the JavaScript level, v2 has tracing built-in using ODPI-C. You set the environment variable DPI_DEBUG_LEVEL to your desired value. You can see information on this here: https://oracle.github.io/odpi/doc/user_guide/debugging.html. For example, to see which SQL statements are executed, set DPI_DEBUG_LEVEL to 16. If you want to see the low-level ODPI-C functions that are being called set DPI_DEBUG_LEVEL to 4. And so forth.

[cjbj]

@jsumners Logging is definitely of interest. The main reason _logStats has an underscore is to allow changes to it when a standard logging framework is added.

[cjbj]

FWIW, There is node-oracledb doc on ODPI-C tracing in Tracing SQL and PL/SQL Statements.

[jsumners]

Tracing SQL is not the same thing as tracing what the library is doing. Look at my example above. The first line in createPool could be:

logger.trace(functionOptionsToBeSerialized, 'attempting to establish connection')

This shows the use that oracledb is:

1. Trying to connect to a database
2. Using the provided options to do so

At this point there isn't any SQL to trace. It's all within the library.

[anthony-tuininga]

Understood. You can use DPI_DEBUG_LEVEL with value 4 to see what the library is actually doing -- but then you are looking at the ODPI-C level and not the node-oracledb level. It can be useful but not as nice as logging, as you pointed out. But we have ODPI-C tracing already there and its something you can use today.