@databases/[email protected]

New Features

• Added bulkInsertStatement utility (#229)

  This returns the SQL statement, rather than immediately executing it. This can be useful because it lets you add ON CONFLICT handlers.

@databases/[email protected]

Bug Fixes

• An error was thrown when a query returns NULL in a column of type TIMESTAMP (#235)

@databases/[email protected]

New Features

• Add --schemaName parameter (#238)

@databases/[email protected]

Bug Fixes

• pg-test run some-command always exited with code 0, even if the command failed (#227)

• Help text for sub-commands was not shown correctly (#227)

@databases/[email protected]

Bug Fixes

• Fix error message typo (#226)

@databases/[email protected]

Bug Fixes

• Fix error message typo (#226)

@databases/[email protected]

Bug Fixes

• mysql-test run some-command always exited with code 0, even if the command failed (#227)

• Help text for sub-commands was not shown correctly (#227)

@databases/[email protected]

Bug Fixes

• Fix error message typo (#226)

@databases/[email protected]

New Features

• Add .andWhere to select queries (#225)

  This lets you add extra conditions to a .bulkFind query. e.g.

  import {gt} from '@databases/pg-typed';
  import db, {users} from './database';
  
  export async function getPostsSince(since: Date) {
    await tables
      .posts(db)
      .bulkFind({
        whereColumnNames: [`org_id`, `user_id`],
        whereConditions: [
          {org_id: 1, user_id: 10},
          {org_id: 2, user_id: 20},
        ],
      })
      .andWhere({created_at: gt(since)})
      .all();
  }

@databases/[email protected]

Bug Fixes

• If a connection was terminated unexpectedly while not fully idle (i.e. in the pool) but also not currently actively executing a query, it could crash the node.js process (#224)

  This happened because @databases/pg was only attaching the idle connection error handler while @databases/pg saw the connection as idle. The issue with this is that it's possible to do non-database async things within a transaction, such as reading and writing files. This could cause a connection to briefly be seen as "active" but not actually be executing a query. If a connection is terminated unexpectedly at that point (e.g. the Postgres server is rebooted) it would throw an unhandled exception.

  We now handle the error and remove the connection from the pool after the transaction.

• We were recycling connections that had errored, providing that we could successfully execute a simple query on the connection. This is wasteful, but more importantly may fail to detect some edge cases where the connection is in an unexpected state (such as stuck in a read only transaction) but is still able to execute the test query. (#224)

  We now check the error that was thrown to determine whether the connection can still be recycled. If the error was anything other than a short list of common errors (various types of constraint violation) we close the connection and get a fresh connection for the pool.