@clickhouse/client-common - npm Package Versions

0.2.10 (Common, Node.js, Web)

New features

• If InsertParams.values is an empty array, no request is sent to the server and ClickHouseClient.insert short-circuits itself. In this scenario, the newly added InsertResult.executed flag will be false, and InsertResult.query_id will be an empty string.

Bug fixes

• Client no longer produces Code: 354. inflate failed: buffer error exception if request compression is enabled and InsertParams.values is an empty array (see above).

0.2.9 (Common, Node.js, Web)

New features

• It is now possible to set additional HTTP headers for outgoing ClickHouse requests. This might be useful if, for example, you use a reverse proxy with authorization. (@teawithfruit, #224)

const client = createClient({
  additional_headers: {
    'X-ClickHouse-User': 'clickhouse_user',
    'X-ClickHouse-Key': 'clickhouse_password',
  },
})

0.2.8 (Common, Node.js, Web)

New features

• (Web only) Allow to modify Keep-Alive setting (previously always disabled). Keep-Alive setting is now enabled by default for the Web version.

import { createClient } from '@clickhouse/client-web'
const client = createClient({ keep_alive: { enabled: true } })

• (Node.js & Web) It is now possible to either specify a list of columns to insert the data into or a list of excluded columns:

// Generated query: INSERT INTO mytable (message) FORMAT JSONEachRow
await client.insert({
  table: 'mytable',
  format: 'JSONEachRow',
  values: [{ message: 'foo' }],
  columns: ['message'],
})

// Generated query: INSERT INTO mytable (* EXCEPT (message)) FORMAT JSONEachRow
await client.insert({
  table: 'mytable',
  format: 'JSONEachRow',
  values: [{ id: 42 }],
  columns: { except: ['message'] },
})

See also the new examples:

• Including specific columns or excluding certain ones instead
• Leveraging this feature when working with ephemeral columns (#217)

0.2.7 (Common, Node.js, Web)

New features

• (Node.js only) X-ClickHouse-Summary response header is now parsed when working with insert/exec/command methods. See the related test for more details. NB: it is guaranteed to be correct only for non-streaming scenarios. Web version does not currently support this due to CORS limitations. (#210)

Bug fixes

• Drain insert response stream in Web version - required to properly work with async_insert, especially in the Cloudflare Workers context.

0.2.6 (Common, Node.js)

New features

• Added Parquet format streaming support. See the new examples: insert from a file, select into a file.

0.2.5 (Common, Node.js, Web)

Bug fixes

• pathname segment from host client configuration parameter is now handled properly when making requests. See this comment for more details.

0.2.4 (Node.js only)

No changes in web/common modules.

Bug fixes

• (Node.js only) Fixed an issue where streaming large datasets could provide corrupted results. See #171 (issue) and #204 (PR) for more details.

0.2.3 (Node.js only)

No changes in web/common modules.

Bug fixes

• (Node.js only) Fixed an issue where the underlying socket was closed every time after using insert with a keep_alive option enabled, which led to performance limitations. See #202 for more details. (@varrocs)

0.2.2 (Common, Node.js & Web)

New features

• Added default_format setting, which allows to perform exec calls without FORMAT clause.

0.2.1 (Common, Node.js & Web)

Breaking changes

Date objects in query parameters are now serialized as time-zone-agnostic Unix timestamps (NNNNNNNNNN[.NNN], optionally with millisecond-precision) instead of datetime strings without time zones (YYYY-MM-DD HH:MM:SS[.MMM]). This means the server will receive the same absolute timestamp the client sent even if the client's time zone and the database server's time zone differ. Previously, if the server used one time zone and the client used another, Date objects would be encoded in the client's time zone and decoded in the server's time zone and create a mismatch.

For instance, if the server used UTC (GMT) and the client used PST (GMT-8), a Date object for "2023-01-01 13:00:00 PST" would be encoded as "2023-01-01 13:00:00.000" and decoded as "2023-01-01 13:00:00 UTC" (which is 2023-01-01 05:00:00 PST). Now, "2023-01-01 13:00:00 PST" is encoded as "1672606800000" and decoded as "2023-01-01 21:00:00 UTC", the same time the client sent.