Синхронизиране

Синхронизирането на bae е синхронизирането на coven: bae декларира своите таблици и blob-ове, а coven прави останалото. Тази страница описва механиката, както важи за bae; собствената документация на coven покрива всяка част в дълбочина.

Улавяне

coven притежава SQLite връзката, така че всеки запис, който bae потвърждава, минава през него. Session разширението на SQLite записва точно какво се е променило във всяка транзакция; промените към синхронизирани таблици стават changeset, запечатан с ключа на библиотеката и подписан с ключа за идентичност на устройството. Няма сравняване на файлове, няма флагове за замърсено състояние: улавянето е свойство на връзката и запис не може да бъде пропуснат.

Потоци

Всяко устройство добавя своите changeset-и към собствен поток в облачния дом, номерирани поред. Устройствата никога не пишат в потоците едно на друго, така че няма конфликти при запис в хранилището, и всяко устройство следи курсор за поток на всеки друг член. Цикълът за синхронизиране качва локалната изходяща опашка, после дърпа потока на всеки друг член от курсора напред, проверявайки подписа на всеки changeset и членството на автора му, преди да го приложи.

Цикълът се изпълнява след локални промени, по таймер при бездействие с отстъпване (до пет минути между проверки) и веднага при Sync Now. Неуспехите отстъпват и опитват отново; цикълът докладва резултата си към интерфейса като състояние, текст на грешка и брой приложени редове.

Сливане

Две устройства, които редактират една и съща библиотека, докато са разделени, са нормалният случай, не изключението. Когато промените им се срещнат:

• Редакции по различни редове или различни колони се прилагат и двете. Редакция на годината на издание на лаптопа и на лейбъла му на настолния компютър дава и двете.
• Редакции по една и съща колона на един и същ ред се подреждат чрез _updated_at хибридния логически часовник на реда: по-късната редакция печели, детерминирано и еднакво на всяко устройство.
• Изтриванията печелят над едновременни редакции: издание, изтрито на едно устройство, остава изтрито, дори ако друго устройство го е редактирало в същия интервал.

Няма интерфейс за конфликти, защото няма неразрешено състояние: всяко устройство стига до един и същ резултат от всеки ред на прилагане.

Стартиране от snapshot

Устройство, което се присъединява или възстановява, не преиграва историята от началото. То изтегля snapshot, пълен SQLite образ, публикуван периодично в облачния дом, после прилага само changeset-ите, които всеки поток е натрупал след него. Метаданните на snapshot-а записват версията на схемата и курсорите по потоци, които той въплъщава.

Версии на схемата

Схемата на bae мигрира през номерирана стълба, а най-горното стъпало на стълбата се записва върху всеки changeset, който устройството пише. Устройство, което дърпа changeset от по-нова схема от собствената си, паркира този поток, без да прилага нищо след него, докато приложението се обнови; нищо не се губи и нищо не се прилага погрешно. Самият файл на базата данни отказва да се отвори под бинарен файл, по-стар от схемата му.

По-едра от версията на схемата е ерата на съвместимост: фиксираната ревизия на coven, вградена във всеки бинарен файл. Две компилации синхронизират само в рамките на една ера; промяна, която чупи мрежовия формат на coven, е нова ера и увеличение на основната версия във всяко приложение. Преди 1.0 всяка компилация е ера нула и форматите се променят без миграция.

Какво вижда доставчикът

В непрозрачен дом доставчикът съхранява шифротекстови changeset-и, шифротекстови blob-ове и подписани записи за членство; може да брои обекти и да наблюдава размери и времена, но не може да прочете нищо от това. Всеки обект, който устройство дърпа, се проверява по подпис и членство, преди нещо да докосне базата данни: хранилището е тъпа, недоверена пощенска кутия. Вижте Шифроване и Идентичност и членство.