meshcore-client

History

Strycher 19858698ee feat(#335 ): add drift and prove it opens on the targets buildable here Step 1 of #335, deliberately before any data migration: prove the store works before trusting it with message history. Adds drift + drift_flutter, a key/value StoredBlobs table mapping 1:1 onto the existing SharedPreferences keys, and verifyReadWrite() as a runtime probe. Key/value rather than relational tables on purpose: it maps directly onto the current store interfaces, so callers do not change and the migration can be verified row-for-row against the old keys. Relational schemas come later, once this is proven and querying is actually wanted. Verified here: - 3 tests pass, including a 6 MiB round-trip - larger than the 5 MiB localStorage cap that makes the web build impossible today - flutter analyze clean - Windows release build succeeds - Web release build compiles Two findings from the gate that a plan-on-paper would have missed: 1. sqlite3_flutter_libs 0.6.0+eol is a DEPRECATED no-op. From sqlite3 v3.x it is unnecessary and drift_flutter already covers it, so it is not a direct dependency here. 2. The web build COMPILES BUT WOULD FAIL AT RUNTIME: drift needs sqlite3.wasm and drift_worker.dart.js shipped in web/, and neither is present. Per drift docs they are downloaded from GitHub releases, version-matched to pubspec.lock (drift 2.34.2, sqlite3 3.5.0), and the server must serve .wasm as Content-Type: application/wasm. Not done here - downloading files needs explicit human approval. Also noted: the drift_dev CLI does not compile at these versions (allSchemaEntities missing from the drift3_preview GeneratedDatabase), so its asset tooling is unavailable. build_runner code generation is unaffected. No user data is touched. No store is switched over. The migration is the next step and remains gated on the web assets question.	1 day ago
..
offband_database_test.dart	feat(#335 ): add drift and prove it opens on the targets buildable here	1 day ago

Strycher 19858698ee feat(#335 ): add drift and prove it opens on the targets buildable here

Step 1 of #335, deliberately before any data migration: prove the store works
before trusting it with message history.

Adds drift + drift_flutter, a key/value StoredBlobs table mapping 1:1 onto the
existing SharedPreferences keys, and verifyReadWrite() as a runtime probe.

Key/value rather than relational tables on purpose: it maps directly onto the
current store interfaces, so callers do not change and the migration can be
verified row-for-row against the old keys. Relational schemas come later, once
this is proven and querying is actually wanted.

Verified here:
- 3 tests pass, including a 6 MiB round-trip - larger than the 5 MiB
  localStorage cap that makes the web build impossible today
- flutter analyze clean
- Windows release build succeeds
- Web release build compiles

Two findings from the gate that a plan-on-paper would have missed:

1. sqlite3_flutter_libs 0.6.0+eol is a DEPRECATED no-op. From sqlite3 v3.x it
   is unnecessary and drift_flutter already covers it, so it is not a direct
   dependency here.

2. The web build COMPILES BUT WOULD FAIL AT RUNTIME: drift needs sqlite3.wasm
   and drift_worker.dart.js shipped in web/, and neither is present. Per drift
   docs they are downloaded from GitHub releases, version-matched to
   pubspec.lock (drift 2.34.2, sqlite3 3.5.0), and the server must serve .wasm
   as Content-Type: application/wasm. Not done here - downloading files needs
   explicit human approval.

Also noted: the drift_dev CLI does not compile at these versions
(allSchemaEntities missing from the drift3_preview GeneratedDatabase), so its
asset tooling is unavailable. build_runner code generation is unaffected.

No user data is touched. No store is switched over. The migration is the next
step and remains gated on the web assets question.

offband_database_test.dart

feat(#335 ): add drift and prove it opens on the targets buildable here