| id | REF-045 | ||||||
|---|---|---|---|---|---|---|---|
| workflow | github | ||||||
| github_issue | emulebb/emulebb#26 | ||||||
| title | Evaluate SQLite-backed storage for local metadata structures | ||||||
| status | OPEN | ||||||
| priority | Minor | ||||||
| category | refactor | ||||||
| labels |
|
||||||
| milestone | post-0.7.3 | ||||||
| created | 2026-05-24 | ||||||
| source | user-requested future backlog item for local metadata storage review |
Workflow status is tracked in GitHub: emulebb/emulebb#26. This local document is retained as an engineering spec/evidence record.
Evaluate whether eMuleBB should move selected local metadata structures from
flat .met, .dat, cache, or sidecar files into a local SQLite store.
This is an evaluation item, not an approved migration. The result should be a compatibility and risk plan that decides which structures benefit from SQLite, which must stay in stock-compatible file formats, and what import/export, backup, and rollback guarantees would be required.
- Known-file metadata and AICH-related indexes.
- Shared-file startup/cache indexes.
- Remote browse inventory caches from FEAT-078.
- Server, Kad, IP-filter, and operational caches only where SQLite gives a clear robustness or queryability win.
- Do not break compatibility for persisted formats that are part of normal eMule profile portability or stock interoperability.
- Do not remove
.met/.datbackups without a migration and recovery plan. - Keep large-library startup, shutdown, and daily-backup costs measurable.
- Keep user-owned profile data exportable and recoverable with common tools.
- Inventory candidate metadata structures and current file formats.
- Classify each candidate as keep flat-file, mirror to SQLite, or migrate.
- Define compatibility, backup, corruption recovery, and downgrade behavior.
- Measure expected startup/shutdown impact for a heavy profile.
- Produce a go/no-go migration plan before any implementation item starts.