Talk about anything
I noticed database schema drift has caused a few regressions over time, including #216 / #237 and, more recently, 27340d0 fixing auto_report_regex_filter being missing from the fresh api_report schema.
Would a small regression test for this be useful?
I can keep it to one androidTest file with no production-code changes or new dependencies:
On a fresh install, derive the columns actually used by the current table adapters (toContentValues()) and verify those columns exist in SQLite.
Create a frozen DB_VERSION 41 schema from 2025-10-31, open it with the current Db, and verify the same table contracts after onUpgrade().
The upgrade fixture would stay within the project's existing ~1-year compatibility policy; I'm not proposing extending support for older databases.
The goal is just to catch cases where application code starts reading/writing a column but onCreate() or an upgrade migration does not create it.
If that sounds useful, I'll keep the PR narrowly scoped to this.
Talk about anything
I noticed database schema drift has caused a few regressions over time, including #216 / #237 and, more recently,
27340d0fixingauto_report_regex_filterbeing missing from the freshapi_reportschema.Would a small regression test for this be useful?
I can keep it to one
androidTestfile with no production-code changes or new dependencies:On a fresh install, derive the columns actually used by the current table adapters (
toContentValues()) and verify those columns exist in SQLite.Create a frozen DB_VERSION 41 schema from 2025-10-31, open it with the current
Db, and verify the same table contracts afteronUpgrade().The upgrade fixture would stay within the project's existing ~1-year compatibility policy; I'm not proposing extending support for older databases.
The goal is just to catch cases where application code starts reading/writing a column but
onCreate()or an upgrade migration does not create it.If that sounds useful, I'll keep the PR narrowly scoped to this.