rust-cli-with-sqlite
Made by JeffDesign SQLite + JSONL sync for Rust CLIs. Use when choosing a source of truth, designing sync strategy, WAL/PRAGMA tuning, atomic JSONL writes, recovery, or durability.
Works With
Quality and Utility come from canonical skill metadata. Community ratings appear separately as stars when subscriber reviews exist.
Subscribe to download
Public previews are available, but downloads, CLI sync, and premium content require an active subscription.
Sign In to Subscribe- Full skill content with deterministic versioning
- CLI sync + local search index
- Access to Jeffrey’s premium library
Save to your account
Saved skills live in your cloud list. Run jsm sync on each machine to pull them locally.
What's New with this Skill
1Updates, enhancements, and release notes for this skill.
New: Rust CLI with SQLite + JSONL, pick a single source of truth, sync one-way, stay atomic
SQLite is fast and ACID; JSONL is human-readable and Git-friendly. Rust CLIs that need both face one decision: which is the source of truth? This skill names that decision, ships a SYNC_STRATEGY template to fill before any code is written and a ready-made RECOVERY_RUNBOOK, lists the WAL/PRAGMA settings that matter, and covers the cross-platform durability details (macOS fullfsync, Windows tempfile persist) that bite in practice.
- Single source of truth rule: pick SQLite or JSONL as primary, and the other is an export or a rebuildable cache. One-way sync, locked, atomic. Two-way sync in a single command is the first anti-pattern
- Two operational docs created up front: SYNC_STRATEGY.md (from assets/SYNC_STRATEGY_TEMPLATE.md, filled before coding) and RECOVERY_RUNBOOK.md (copied from assets/RECOVERY_RUNBOOK.md)
- WAL + sensible sync: journal_mode = WAL, synchronous = NORMAL (or FULL for critical data), wal_autocheckpoint = 1000, plus a busy timeout and foreign keys on
- Cross-platform durability: macOS needs fullfsync=ON to match Linux and Windows; on Windows, use tempfile::persist() for the atomic replace
- Version markers in both stores (data version or last_synced_at), compared at startup, so a stale store can't silently overwrite newer data
- Atomic JSONL writes: temp file in the same directory, fsync, rename; the old file is kept on failure. Recovery ships as import-jsonl and export-jsonl commands, with Git history as the fallback
- Non-goals are explicit: not a general SQLite tutorial, not ORM selection, not real-time replication. Use when SQLite for queries + JSONL for git workflow + cross-platform sync
- Validation loop: PRAGMA integrity_check, compare counts and a stable hash after sync, and simulate a crash mid-sync to verify recovery
The core rule: one source of truth, one-way sync, locked and atomic. The skill's decision tree picks SQLite as the source of truth when you need the fastest queries and ACID writes (JSONL becomes a periodic export), or JSONL when you need a human-editable, git-first source (the database becomes a rebuildable cache). Brief divergence is expected; fast eventual consistency is required. Two-way sync in a single command is the first anti-pattern on the list.