Синхронізація

Синхронізація bae — це синхронізація coven: bae оголошує свої таблиці й blobs, а coven робить решту. Ця сторінка описує механіку в тому вигляді, у якому вона застосовується до bae; власна документація coven докладно описує кожну частину.

Захоплення

coven володіє SQLite-з’єднанням, тож кожен запис, який bae фіксує, проходить через нього. Session extension SQLite записує саме те, що змінилося в кожній transaction; зміни в синхронізованих таблицях стають changeset, запечатаним ключем бібліотеки й підписаним ключем ідентичності пристрою. Без порівняння, без dirty flags: захоплення є властивістю з’єднання, і запис не може бути пропущений.

Streams

Кожен пристрій додає свої changesets до власного stream у хмарному домі, послідовно пронумеровані. Пристрої ніколи не пишуть у streams одне одного, тож у сховищі немає конфліктів запису, і кожен пристрій тримає cursor для кожного peer stream. Цикл синхронізації спершу надсилає локальну outbox, потім забирає stream кожного peer від свого cursor уперед, перевіряючи підпис кожного changeset і участь його автора перед застосуванням.

Цикл працює після локальних змін, за idle timer із паузами (до п’яти хвилин між опитуваннями) і відразу через Sync Now. Збої відступають і повторюються; цикл повідомляє інтерфейсу результат кожного проходу як status, error text і кількість застосованих rows.

Об’єднання

Редагування тієї самої бібліотеки на двох пристроях окремо — звичайний випадок, не виняток. Коли їхні зміни зустрічаються:

• Редагування різних рядків або різних стовпців застосовуються обидва. Редагування року релізу на ноутбуку і його лейблу на настільному комп’ютері дає обидва.
• Редагування того самого стовпця того самого рядка впорядковуються за _updated_at hybrid logical clock рядка: пізніше редагування виграє, визначено й однаково на кожному пристрої.
• Видалення виграють над одночасними редагуваннями: реліз, видалений на одному пристрої, лишається видаленим, навіть якщо інший пристрій редагував його в той самий проміжок.

Інтерфейсу конфліктів немає, бо немає нерозв’язаного стану: кожен пристрій сходиться до того самого результату за будь-якого порядку застосування.

Початкове завантаження

Пристрій, що приєднується або відновлюється, не програє історію з початку. Він завантажує snapshot, повний образ SQLite, періодично опублікований у хмарний дім, а потім застосовує лише changesets, накопичені кожним stream після нього. Метадані snapshot записують версію схеми і курсори потоків, які він утілює.

Версії схеми

Схема bae мігрує нумерованими сходами, і верхня сходинка вшивається в кожен changeset, який пише пристрій. Пристрій, що отримує changeset зі схеми новішої за власну, відкладає цей stream, не застосовуючи нічого після нього, доки застосунок не оновиться; нічого не втрачається й нічого не застосовується неправильно. Сам файл бази даних відмовляється відкриватися під бінарним файлом, старішим за свою схему.

Грубіша за версію схеми — ера сумісності: закріплена ревізія coven, вшита в кожен бінарний файл. Дві збірки синхронізуються лише в межах ери; злам формату передавання coven — це нова ера і підвищення основної версії у кожному застосунку. До 1.0 кожна збірка має ера нуль, і формати змінюються без міграції.

Що бачить провайдер

У непрозорому домі провайдер зберігає зашифровані changeset-и, зашифровані blob-и і підписані записи участі; він може рахувати об’єкти й спостерігати розміри та час, але нічого не читати. Кожен об’єкт, який забирає пристрій, перевіряється, підпис і участь, перед тим як щось торкнеться бази даних: сховище є пасивною ненадійною поштовою скринькою. Див. Шифрування і Ідентичність та участь.