v_chat_persistence_drift 0.1.0-rc.3

Drift offline persistence adapter for the V Chat end-user SDK.

v_chat_persistence_drift

Release candidate 0.1.0-rc.3 is the Drift persistence package in the coordinated V Chat Flutter SDK. Add it with dart pub add v_chat_persistence_drift. It requires v_chat_core: ^0.1.0-rc.3 and Dart >=3.10.0-0 <4.0.0.

See the repository support, security, and privacy policies before production adoption.

Production OfflineStore adapter using Drift.

All rows contain scope_key. Every select, update, delete, uniqueness check, retention count, transaction, reset, and purge includes it. Schema version 3 stores durable entities, bounded page metadata, approved pending commands, reconnect checkpoints, and bounded dead-letter events. It never stores app-user tokens, presence, typing, heartbeat, or connection state.

Schema v3 persists replay provenance. Commands from older schemas are preserved as terminal, non-replayable rows. Legacy dead-letter strings are irreversibly sanitized during migration, and new quarantine stores only positional container shape, redacted scalars/type, and a closed reason code.

applySyncBatch commits entity mutations together with optional page/checkpoint state. resetCachedState clears cache/checkpoints/quarantine while preserving pending commands; purgeScope removes every category for explicit account cleanup.

loadEntity and mergeVersionedEntity provide the SDK-FL-004 exact channel-cache boundary. Monotonic merge compares the stored server sequence in one transaction, so a late older response cannot replace a newer channel version. These operations use the existing schema-v3 scoped primary key and do not expose generated rows or SQL.

SDK-FL-005 stores only the authenticated user's active membership/channel projection in the same scoped entity table. A complete bounded refresh commits upserts and missing-row deletions together; partial traversal never deletes. No remote cursor, app-user token, read state, unread count, message preview, or app-server membership DTO is persisted.

SDK-FL-006 stores confirmed top-level messages and tombstones in the same exact-scope entity table. mergeVersionedEntities atomically applies one bounded page while preserving a higher existing message version against late responses. Immutable sequence sort keys provide deterministic local history paging. No pending content, mutation command, token, or remote cursor is stored, and schema version 3 remains unchanged.

SDK-FL-010 reuses those schema-v3 scoped entities to commit accepted realtime channel/message and current-user conversation/membership/unread replacements before callbacks. It also reuses bounded, sanitized dead letters for invalid or compatible-future event envelopes. Event processing adds no table, column, index, token, content-bearing diagnostic, or generated Drift change.

SDK-FL-011 reuses the schema-v3 entity and checkpoint tables. Durable channel events commit the monotonic entity and exact realtime.v1.<clientInstanceId>.<cid> sequence in one transaction. Checkpoint listing/reset is bounded to 100 rows and applies both the full app-user scope and an exact validated client-instance prefix. Checkpoints contain no credentials or event payloads, and the feature requires no schema migration or generated Drift edit.

SDK-FL-013 keeps schema version 3 and stores top-level messages, direct replies, root thread summaries, private current-user thread state, and completed first-page thread markers as separate scoped entity types. Replies never enter ordinary cached history. A thread cache is readable only after its exact ordered first-page marker commits, so a partial refresh or realtime reply cannot fabricate page membership. Realtime reply entity, root-summary, and checkpoint changes use one existing batch transaction; remote cursors and offline reply/read commands are never persisted.

SDK-FL-014 keeps schema version 3 and stores one bounded message_reaction_summary entity per cached message. Its server sequence is the reaction-summary version, independent from message edit versions. REST batches and ordered realtime deltas preserve higher summaries, reject equal-version conflicts, and atomically advance an available channel checkpoint. Reactor pages, reaction commands, tokens, and user profiles are never persisted.

SDK-FL-021 reuses the schema-v3 entity table for exact owner-scoped attachment metadata and versioned deletion tombstones. Exact watches use the existing scoped identity key. Attachment bytes, file streams, signed URLs, signed headers, object keys, and transfer progress never enter Drift, and no schema or generated database change is required.

SDK-FL-022 reuses the same scoped entity table for content-light notification receipts. Claim, exact replay/conflict detection, seven-day expiry, and oldest-first 512-row retention execute in one transaction. Receipts contain only the event ID and canonical route fingerprint; provider tokens, addresses, credentials, raw payloads, and message content are never persisted. Schema version 3 and generated Drift source remain unchanged.

Generate code before analysis or tests:

dart run build_runner build --delete-conflicting-outputs