Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Running node with --trace-sync-io for an application that uses knex outputs warnings such as this one:
Using a synchronous API is undesirable even if the randomBytes() function is normally very fast. If for no other reason, just for the fact that it makes --trace-sync-io much less useful when knex creates a lot of noise.
Looking at the use if uuid.v4() in knex master branch (commit a613fe2):
Is __knexQueryUid actually used?
If it is, does it require just uniqueness from the uuid or the additional cryptographic randomness of uuid v4? If uniqueness is sufficient a uuid.v1() will provide that just as well as uuid.v4(), but 5 times faster and without triggering the --trace-sync-io warning.
Here is a small perf experiment comparing v1 and v4 uuid generation:
It is used to allow to certain event handlers to know that some events are happening to the same query.
Perf is not an issue here, since it is not any bottleneck in knex query execution. But getting rid off the
Running a program that uses knex with node --trace-sync-io results in warnings such as this one: (node:10232) WARNING: Detected use of sync API at randomBytes (internal/crypto/random.js:54:31) at nodeRNG ([...]/node_modules/uuid/lib/rng.js:7:17) at v4 ([...]/node_modules/uuid/v4.js:13:52) at toSQL ([...]/node_modules/knex/lib/query/compiler.js:73:28) at toSQL ([...]/node_modules/knex/lib/query/builder.js:77:44) at [...]/node_modules/knex/lib/runner.js:30:36 at [...]/node_modules/knex/lib/runner.js:253:24 at tryCatcher ([...]/node_modules/knex/node_modules/bluebird/js/release/util.js:16:23) at [...]/node_modules/knex/node_modules/bluebird/js/release/promise.js:547:31 uuid.v1() provides more than adequate collision guarantees, is 5 times faster than uuid.v4() and most importantly do not trigger the warning above.