rouggy
c48294b0ca
Correcting an over-design of my own. I had contacts given an identity in bulk the first time synchronisation was switched on, and a full dedupe-key map of the logbook rebuilt on every pass, both sized for 123 000 contacts. Neither is needed, because the change log starts EMPTY. Contacts logged before synchronisation was switched on are never in anyone's log and so are never exchanged; an identity is stamped only on a contact that is actually logged, edited or deleted from then on. Seeding a second machine with the existing history is a one-time copy of the database or an ADIF import — not something synchronisation should be doing, and not something it can do from a file that starts empty. One case survives, and it is why the dedupe key stays. Two machines can already hold the SAME old contact, the second seeded by that copy or import, with different row ids and no identity on either. The day one of them edits it, it stamps an identity and sends a change naming it; the other has never seen that identity and would insert a duplicate. Matching on the contact itself — callsign, minute, band, mode, the importer's own key — recognises it. So that became a targeted lookup through idx_qso_callsign, run only when an identity is unknown, instead of a whole-table map rebuilt each pass. Rare work, priced as rare work.
25 lines
1.5 KiB
SQL
25 lines
1.5 KiB
SQL
-- A stable identity per contact, for folder-based synchronisation.
|
|
--
|
|
-- Two PCs exchanging changes through a shared folder need to name the SAME
|
|
-- contact in both logs. "the QSO with M0ABC at 14:32" is a guess, and the two
|
|
-- machines can disagree about which row that is — so an edit or a deletion
|
|
-- cannot be addressed at all without an identity that travels with the record.
|
|
--
|
|
-- A REAL COLUMN, indexed, rather than a key inside extras_json. The identity is
|
|
-- looked up once per incoming change, and on a 120 000-QSO logbook scanning
|
|
-- JSON for it would turn every sync into a full table read. A column costs one
|
|
-- migration; the JSON would cost a scan every time.
|
|
--
|
|
-- sync_uid is listed in varcharColumns (internal/db/mysql.go): MySQL cannot
|
|
-- index a TEXT column without a prefix length, and a migration that tries dies
|
|
-- with error 1170 on every startup thereafter, with no way out from the UI.
|
|
--
|
|
-- Empty on every existing row, and it STAYS empty on most of them. The change
|
|
-- log starts empty too, so contacts logged before synchronisation was switched
|
|
-- on are never exchanged: nothing has to be copied across, and an identity is
|
|
-- stamped only on a contact that is actually logged, edited or deleted from
|
|
-- then on. Seeding a second machine with the existing log is a one-time copy of
|
|
-- the database or an ADIF import, not something synchronisation does.
|
|
ALTER TABLE qso ADD COLUMN sync_uid TEXT NOT NULL DEFAULT '';
|
|
CREATE INDEX IF NOT EXISTS idx_qso_sync_uid ON qso (sync_uid);
|