Skip to content

Evaluate SQLite-backed storage for local metadata structures

Workflow status is tracked in GitHub: https://github.com/emulebb/emulebb/issues/26. This local document is retained as an engineering spec/evidence record.

Summary

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.

Candidate Areas

  • 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.

Constraints

  • Do not break compatibility for persisted formats that are part of normal eMule profile portability or stock interoperability.
  • Do not remove .met/.dat backups 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.

Acceptance Criteria

  • [ ] 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.