je to tak, lesson learnt. Idea byla takova mit SQLite (in memory) pro jednodussi nasazovani integracnich testu (coz je skutecne snadny), ale prave proto, ze to chtelo jen nejmensi spolecnej jmenovatel moznosti SQL, to padlo. Resp. nez to padlo, tak se zacaly v kodu (a hlavne v migracich) objevovat switche s vyberem prikazu per databaze, to uz bylo zly :-)
A pak testy běží nad jinou DB než produkce, to už jsem zažil… Nevím přesně, co to bylo, ale i pro SQLite je možné napsat dotaz, který PostgreSQL odmítne.
Udělat separátní instanci PostgreSQL není až tak těžké (zvlášť v době Dockeru, ale i bez něj). Lze tomu vypnout fsync, což sice v produkci asi nechcete, ale pro testy, kde stejně pokaždé vytvoříte novou DB, to může být OK volba, která přinese zajímavé zrychlení. V podstatě není potřeba čekat na zápis, a s dostatkem RAM máme něco jako in-memory DB.
S tím, jak je snadné rozjet PostgreSQL s vypnutým fsync, nevidím důvod řešit vedle toho ještě SQLite. A vypnutí fsync to umí významně zrychlit. (Samozřejmě za cenu možných nekonzistencí při nečekaném vypnutí, ale pokud tu DB v takovém případě stejně zahodím, tak mě to netrápí…) Teoreticky by vypnutí fsync mohlo být řádově srovnatelné s in-memory, ale benchmark nemám.
Hlavne u SQLite jsou typy sloupců jen tak naoko. Mé nedávné a docela nepříjemné zjištění.
```
$ sqlite3
SQLite version 3.42.0 2023-05-16 12:36:15
Enter ".help" for usage hints.
sqlite> CREATE TABLE test( value int );
sqlite> INSERT INTO test(value) VALUES ('xxx');
sqlite> SELECT * FROM test;
xxx
sqlite> .schema test
CREATE TABLE test( value int );
```
Ono jde ten type check zapnout. Kdo dělá s SQLite, tak to asi ví. Ale ten kdo používá SQLite jen jako náhradu Postgre pro lokální vývoj nebo pro testy, ten může být nepříjemně překvapen.
https://www.sqlite.org/stricttables.html
```
sqlite> CREATE TABLE test( value int ) STRICT;
sqlite> INSERT INTO test(value) VALUES ('xxx');
Runtime error: cannot store TEXT value in INT column test.value (19)
```