Legacy Merge

The older partial-database importer, kept for legacy cases; most users want Library Bundle instead.

Last updated 6/10/2026

File → Advanced → Merge Partial Database (legacy)... is the original attach-based DB importer. It predates the Library Bundle workflow and only handles ~12 of the current schema's ~28 user-data tables. Anything outside its allowlist is silently dropped.

You almost certainly want Library Bundle instead. Bundle covers all 15+ user-data tables, includes assets, validates schema versions, and offers a Preview / dry-run. Legacy merge exists for legacy use cases and pending eventual removal.

When you might still use it

  • You have an old .db file from before bundles existed and only need core tables (events, days, session_notes, videos, performance, track/layout/corners).
  • You're scripting a sync workflow against the same code path via the tools/full_db_import.py CLI.

What gets merged

Legacy merge covers a fixed set of core tables. It currently handles:

  • tracks, track_layouts, track_corners
  • user_corner_profiles, user_corner_labels
  • events, days, day_drivers
  • session_notes, session_text_notes, session_performance
  • videos

Everything else — markers, feedback, telemetry imports, video alignments, AI summaries, publications, stints, lap times — is silently skipped.

Per-table merge is last-write-wins by updated_at, with two narrow special cases that preserve local file paths when the incoming row is missing them: session_notes.session_path and days.day_folder_path / event_day_label.

The preflight modal

Before any merge runs, LapInsight introspects the source DB read-only and shows a structured report:

  • Schema versions on both sides. If the source schema is newer than local, the merge is hard-blocked — the modal won't even let you proceed. Update LapInsight first.
  • Tables that will be SKIPPED — every table present in the source that isn't on the importer's allowlist, with row counts.
  • Columns that will be DROPPED — columns in the source that don't exist locally for tables in the allowlist (uncommon; this happens if the source is on a newer schema for a covered table).

The Proceed with merge button stays disabled until you tick "I understand that data outside the importer's allowlist will be dropped." Cancel is the default. Even after acknowledging, the merge auto-creates a pre-merge backup before doing any writes — see Backup & Restore — so a one-step rollback is always available.

Future-proofing

The preflight is purely runtime-driven. It opens both DBs read-only, queries sqlite_master and PRAGMA table_info, and diffs against the importer's allowlist. When new migrations land, the preflight automatically reflects them — no preflight code changes needed.

The single moving piece is the importer's DEFAULT_TABLE_ORDER constant. As long as it stays at 12 tables, every new migration grows the "skipped" list and reinforces the "use Library Bundle instead" recommendation.

Why we keep it

The legacy merger predates Library Bundle and remains the documented entry point for some power-user CLI scripts. It's behind an Advanced submenu rather than removed because:

  1. Existing users who relied on Import Database... retain a path forward.
  2. The CLI tool (tools/full_db_import.py) keeps working unchanged.
  3. The preflight modal makes the data-loss boundary explicit — silent corruption isn't possible.

Eventual removal is gated on Library Bundle covering every documented multi-laptop consolidation use case.

CLI equivalent

``powershell python tools/full_db_import.py --source path/to/other.db ``

Same code path as the GUI action; same 12-table allowlist; auto-creates the same pre-merge backup. The CLI does not run the preflight modal — pass --no-backup only if you have your own snapshot strategy.

See also