They don't by default, because they didn't in older versions of
SQLite and some older applications might rely on that. You have to
send an explicit pragma prior to opening a transaction to make them
take effect.
Yarn is the better package manager IMO, but npm comes with node and
using it does make the end-user installation experience a little
simpler as a result.
We'll keep the door open for side-by-side support of Postgres in
the background, but due to SQLite's type system quirks we cannot
use the same DDL for both databases, so we would have to maintain
two sets of DDL (schema init and schema migration scripts) at once.
Interested future contributors can shoulder this maintenance burden
if they so choose.
Everything is a scalar value now, and while this does involve more
boilerplate it will also catch type conversion issues like
"1" + 0 === "10" in the future.
This is in preparation for a transition to SQLite, which sadly does
not support array-valued columns (or indeed have much of a type
system in general).
This commit declares and type-checks the following clauses:
* limit().offset() chains on SelectStatement
* onConflict().doUpdate() chains on InsertStatement
We need to flesh out the other possibilities for onConflict() in
particular before all these changes get submitted as an upstream
PR.
This will allow us to cleanly extend these interfaces with
additional clauses understood by Postgres, which we can then chain
without having to redeclare the entire interface.
Wrap everything in a module instead of a namespace. I'm still not
entirely clear on what the distinction is but the forked typings
don't seem to get applied without this change.
This is in preparation for a transition to SQLite. SQLite does have
a similar concept called "attached databases", but it's kind of a
pain to deal with if you're casually browsing a database from the
`sqlite3` CLI so we'll just use some slightly uglier explicitly
namespaced table name identifiers instead.
Tau