v0.1.0

Database errors are now catchable as java.sql.SQLException on both backends, and byte arrays round-trip as SQLite blobs and postgres bytea.

Catchable SQL errors

Errors carry :jdbc/sql-error in their ex-data and satisfy (catch java.sql.SQLException ...). That is the contract migratus depends on: its table-exists? probe catches SQLException to decide whether it still needs to create schema_migrations, and on a fresh database that probe used to escape instead of letting migratus bootstrap.

Binary values

A byte array parameter binds as a blob or bytea, and those columns read back as byte arrays. The bytes round-trip exactly, so embedded NULs, non-UTF-8 bytes and empty payloads all survive.

(jdbc/execute! conn "create table doc (id integer primary key, body blob)")
(jdbc/insert! conn :doc {:body (byte-array [0 255 65])})
(:body (jdbc/fetch-one conn "select body from doc"))   ; -> byte array

On postgres a byte array is sent in binary with its Oid given as bytea, so the parameter carries its own type rather than depending on the statement offering a bytea column for the server to infer one from. Reads still come back in text format and handle both bytea_output encodings, hex and escape.

Upgrading

One behavior change to be aware of: a bare select ? with a byte array parameter now returns a byte array, where it previously returned the literal \x... string the driver had sent. Binding a byte array against a non-bytea column is unaffected; text columns store the same value as before, and types like integer or json errored before and error now, with a clearer message.

Changes

• #5 Make SQLite errors catchable and support BLOB values, thanks to @sundbp
• #6 Give postgres the same SQL error and binary value behavior as sqlite
• #7 Bind postgres byte arrays in binary with an explicit bytea Oid