Proposal made by Hubert here
Background
SQLiteProvider is the storage adapter Onyx uses on iOS and Android, built on top of react-native-nitro-sqlite. It owns every read, write, and merge that hits the on-device database — including hand-written SQL, JSON_PATCH/JSON_REPLACE merge logic, parameter binding, and the IN-list batch paths used during sync.
Onyx's existing test suite runs entirely in Node via Jest. Because react-native-nitro-sqlite is a native module with no Node implementation, the suite globally stubs it out in jestSetup.js, so the provider's SQL and merge code never actually executes against a database in CI. Today, the only way to exercise this code is to run the App on a real device or simulator.
Problem
When a developer changes a query, parameter binding, or merge path in SQLiteProvider, it may introduce SQL-shaped bugs (broken JSON_PATCH semantics, mis-bound :value placeholders, escaping mistakes, batch transaction errors). The only way to catch this today is via manual testing — which is slow, inconsistent, and easy to skip. Bugs may ship unnoticed and surface on users' devices.
Proposed Solution
Add a Jest mock of react-native-nitro-sqlite backed by an in-memory better-sqlite3 database, plus a new SQLiteProviderTest.ts that drives the real provider end-to-end against it.
- The mock implements the slice of the Nitro surface the provider uses and maps Nitro's positional params onto
better-sqlite3's named bindings so existing SQL runs unmodified.
- The suite covers:
setItem/getItem, multiSet/multiGet, multiMerge (both JSON_PATCH shallow/deep and JSON_REPLACE via replaceNullPatches), removeItem/removeItems, getDatabaseSize, clear, and SQL-injection safety on record_key.
- Everything runs on the same CI that already runs the rest of the suite, on every PR — so the next SQL change is caught in seconds instead of in production.
- No new patterns introduced: this follows the same approach already used in
IDBKeyValProviderTest.
Draft PR
Expensify/react-native-onyx#794
Issue Owner
Current Issue Owner: @sosek108
Proposal made by Hubert here
Background
SQLiteProvideris the storage adapter Onyx uses on iOS and Android, built on top ofreact-native-nitro-sqlite. It owns every read, write, and merge that hits the on-device database — including hand-written SQL, JSON_PATCH/JSON_REPLACE merge logic, parameter binding, and the IN-list batch paths used during sync.Onyx's existing test suite runs entirely in Node via Jest. Because
react-native-nitro-sqliteis a native module with no Node implementation, the suite globally stubs it out injestSetup.js, so the provider's SQL and merge code never actually executes against a database in CI. Today, the only way to exercise this code is to run the App on a real device or simulator.Problem
When a developer changes a query, parameter binding, or merge path in
SQLiteProvider, it may introduce SQL-shaped bugs (brokenJSON_PATCHsemantics, mis-bound:valueplaceholders, escaping mistakes, batch transaction errors). The only way to catch this today is via manual testing — which is slow, inconsistent, and easy to skip. Bugs may ship unnoticed and surface on users' devices.Proposed Solution
Add a Jest mock of
react-native-nitro-sqlitebacked by an in-memorybetter-sqlite3database, plus a newSQLiteProviderTest.tsthat drives the real provider end-to-end against it.better-sqlite3's named bindings so existing SQL runs unmodified.setItem/getItem,multiSet/multiGet,multiMerge(bothJSON_PATCHshallow/deep andJSON_REPLACEviareplaceNullPatches),removeItem/removeItems,getDatabaseSize,clear, and SQL-injection safety onrecord_key.IDBKeyValProviderTest.Draft PR
Expensify/react-native-onyx#794
Issue Owner
Current Issue Owner: @sosek108