3 ms·

Something I see some developers do which I don't recommend is using SQLite for testing environments when they're using PostgreSQL in production. SQLite3 doesn't

Something I see some developers do which I don't recommend is using SQLite for testing environments when they're using PostgreSQL in production. SQLite3 doesn't support a lot of types that PostgreSQL does and it doesn't support things like full outer joins. Save the headaches of debugging in production and spin up a docker PostgreSQL instance since testing environments should emulate production environments as much as possible.

ebg13 7y ago
> and it doesn't support things like full outer joins This at least is possible to fake. But in the era of premade docker packages for postgres, I do wonder why the practice you describe persists.
- miguelmota 7y ago
  I know some people with a certain generation of Macbook or macOS version have had bad luck running docker which causes their fan to go nuts and resources get drained so they prefer to avoid docker if possible.
to11mtm 7y ago
Depends. The Micro-Orm I use in C# manages to work around this well enough; the only thing SQLite is really hard to work with is Time since there's no real structure defined for it.
oftenwrong 7y ago
Yes, I often see Java developers using an embedded H2 database [1] for development and test, and a "real" database in production, and there are always unexpected issues of false-positive tests and functionality due to this. Terrible anti-pattern. I am glad "Dev/prod parity" is recognised in The Twelve-Factor App manifesto [2]. I do what you suggest: run dev/test against a real PostgreSQL (of the same version) running in a container. In fact, I take this further and run builds against an actual PostgreSQL, since I like to generate code based on the DB schema using jOOQ [3]. The build proceeds like so: 1. Spin up a fresh PostgreSQL container 2. Run my schema migrations against it 3. Run the jOOQ code generator against it 4. Compile code This provides some additional guarantees, including: 1. My queries are fully type-safe from my code down to the database schema level 2. My schema migrations can be run against an empty database [1] https://www.h2database.com/html/main.html https://www.h2database.com/html/main.html [2] https://12factor.net/dev-prod-parity https://12factor.net/dev-prod-parity [3] https://www.jooq.org/doc/3.13/manual/code-generation/ https://www.jooq.org/doc/3.13/manual/code-generation/

ebg13 7y ago

> and it doesn't support things like full outer joins This at least is possible to fake. But in the era of premade docker packages for postgres, I do wonder why the practice you describe persists.

miguelmota 7y ago
I know some people with a certain generation of Macbook or macOS version have had bad luck running docker which causes their fan to go nuts and resources get drained so they prefer to avoid docker if possible.

to11mtm 7y ago

Depends. The Micro-Orm I use in C# manages to work around this well enough; the only thing SQLite is really hard to work with is Time since there's no real structure defined for it.

oftenwrong 7y ago

Yes, I often see Java developers using an embedded H2 database [1] for development and test, and a "real" database in production, and there are always unexpected issues of false-positive tests and functionality due to this. Terrible anti-pattern. I am glad "Dev/prod parity" is recognised in The Twelve-Factor App manifesto [2]. I do what you suggest: run dev/test against a real PostgreSQL (of the same version) running in a container. In fact, I take this further and run builds against an actual PostgreSQL, since I like to generate code based on the DB schema using jOOQ [3]. The build proceeds like so: 1. Spin up a fresh PostgreSQL container 2. Run my schema migrations against it 3. Run the jOOQ code generator against it 4. Compile code This provides some additional guarantees, including: 1. My queries are fully type-safe from my code down to the database schema level 2. My schema migrations can be run against an empty database [1] https://www.h2database.com/html/main.html https://www.h2database.com/html/main.html [2] https://12factor.net/dev-prod-parity https://12factor.net/dev-prod-parity [3] https://www.jooq.org/doc/3.13/manual/code-generation/ https://www.jooq.org/doc/3.13/manual/code-generation/