Current State
Followup of #947
Problem
After a GSAK backup import, the distances of each imported database are recalculated with recalculate_distances() on the GUI thread: for the active database in _refresh_after_import(), for every other database the first time you switch to it (_on_database_switched). On large databases this freezes the UI for a noticeable time.
There is also a gap in distances_up_to_date(). It only spot-checks the lowest-id cache, so after a merge import it can report "up to date" while the newly added caches still have distance = NULL.
Proposed Improvement
Proposed fix
GsakImportWorker brings each target database's distances up to date while it is already running in the background, right after the import.recalculate_distances() / distances_up_to_date() take an optional db_path. While the worker has the engine switched to a target database, db_settings is not bound to it, so dist_calc_* has to be read from and written to that file's own db_settings table. Otherwise it would end up in the active database's legacy opensak.json keys.- New helpers
db_settings.peek_value() / write_file() (never create a missing file; writing drops the cache) and AppSettings.home_for_db_file().
- After a GSAK import, the main window only recalculates if
distances_up_to_date() can't confirm the distances. The check on database switch stays as a safety net. Other imports (GPX etc.) keep recalculating every time.
distances_up_to_date() also returns False when any cache with coordinates has distance IS NULL.
Acceptance criteria
Branch: improvement/gsak-import-recalc-distances-in-worker
Expected Benefits
No response
Current State
Followup of #947
Problem
After a GSAK backup import, the distances of each imported database are recalculated with
recalculate_distances()on the GUI thread: for the active database in_refresh_after_import(), for every other database the first time you switch to it (_on_database_switched). On large databases this freezes the UI for a noticeable time.There is also a gap in
distances_up_to_date(). It only spot-checks the lowest-id cache, so after a merge import it can report "up to date" while the newly added caches still havedistance = NULL.Proposed Improvement
Proposed fix
GsakImportWorkerbrings each target database's distances up to date while it is already running in the background, right after the import.recalculate_distances()/distances_up_to_date()take an optionaldb_path. While the worker has the engine switched to a target database,db_settingsis not bound to it, sodist_calc_*has to be read from and written to that file's owndb_settingstable. Otherwise it would end up in the active database's legacyopensak.jsonkeys.db_settings.peek_value()/write_file()(never create a missing file; writing drops the cache) andAppSettings.home_for_db_file().distances_up_to_date()can't confirm the distances. The check on database switch stays as a safety net. Other imports (GPX etc.) keep recalculating every time.distances_up_to_date()also returnsFalsewhen any cache with coordinates hasdistance IS NULL.Acceptance criteria
dist_calc_*is stored in their own settings table.Branch:
improvement/gsak-import-recalc-distances-in-workerExpected Benefits
No response