동기화

bae의 동기화는 coven의 동기화입니다. bae가 table과 blob을 선언하면 coven이 나머지를 합니다. 이 페이지는 bae에 적용되는 동작을 설명합니다. coven 자체 문서는 각 부분을 더 깊게 다룹니다.

캡처

coven은 SQLite 연결을 소유하므로 bae가 커밋하는 모든 write는 coven을 통과합니다. SQLite의 session extension은 각 transaction에서 정확히 무엇이 바뀌었는지 기록합니다. synced table의 변경은 changeset이 되고, library key로 봉인되며 기기의 identity key로 sign됩니다. diffing도 dirty flag도 없습니다. 캡처는 연결의 속성이므로 write를 놓칠 수 없습니다.

스트림

각 기기는 자기 changeset을 클라우드 홈의 자기 스트림에 순서 번호를 붙여 추가합니다. 기기는 서로의 스트림에 쓰지 않으므로 저장소에서 쓰기 충돌이 없고, 각 기기는 피어 스트림별 커서를 추적합니다. 동기화 주기는 로컬 송신함을 보낸 뒤 각 피어의 스트림을 커서 이후부터 가져오고, 각 changeset의 서명과 작성자 구성원 자격을 검증한 뒤 적용합니다.

Cycle은 local change 뒤, backoff가 있는 idle timer(최대 poll 간격 5분), 그리고 Sync Now 즉시 실행으로 동작합니다. 실패하면 backoff 후 재시도합니다. Loop는 각 cycle 결과를 status, error text, 적용된 row 수로 UI에 보고합니다.

병합

두 기기가 떨어져 있는 동안 같은 라이브러리를 편집하는 것은 예외가 아니라 일반적인 경우입니다. 변경이 만날 때:

• 서로 다른 row 또는 서로 다른 column 편집은 둘 다 적용됩니다. 노트북에서 릴리스의 year를 고치고 데스크톱에서 label을 고치면 둘 다 남습니다.
• 같은 row의 같은 column 편집은 row의 _updated_at hybrid logical clock으로 순서가 정해집니다. 나중 편집이 모든 기기에서 결정적으로 똑같이 이깁니다.
• Deletes win over concurrent edits: 한 기기에서 삭제한 릴리스는 같은 간격에 다른 기기에서 편집됐더라도 삭제된 상태로 남습니다.

해결되지 않은 상태가 없기 때문에 conflict UI가 없습니다. 어떤 적용 순서에서도 모든 기기는 같은 결과로 모입니다.

초기화

참가하거나 복구하는 기기는 기록을 처음부터 재생하지 않습니다. 클라우드 홈에 주기적으로 게시되는 전체 SQLite 이미지인 snapshot을 내려받고, 그 뒤 각 스트림에 쌓인 changeset만 적용합니다. 스냅샷 메타데이터는 스키마 버전과 그 안에 담긴 스트림별 커서를 기록합니다.

스키마 버전

bae의 스키마는 번호가 붙은 단계로 마이그레이션되며, 그 최상위 단계가 기기가 쓰는 모든 changeset에 찍힙니다. 기기가 자기보다 새 스키마의 changeset을 가져오면, 앱이 업데이트될 때까지 그 스트림을 보류 상태로 두고 그 뒤의 것은 아무것도 적용하지 않습니다. 아무것도 잃지 않고 잘못 적용되지도 않습니다. 데이터베이스 파일 자체도 자기 스키마보다 오래된 바이너리에서는 열리지 않습니다.

스키마 버전보다 큰 단위가 호환성 시대입니다. 각 바이너리에 포함된 고정 coven 리비전입니다. 두 빌드는 같은 시대 안에서만 동기화합니다. coven 전송 형식의 호환성 파괴는 새 시대이며 모든 앱의 주 버전 증가입니다. 1.0 전에는 모든 빌드가 시대 0이고 형식은 마이그레이션 없이 바뀝니다.

제공자가 보는 것

불투명 홈에서 제공자는 암호문 changeset, 암호문 blob, 서명된 구성원 레코드를 저장합니다. 객체 수와 크기 및 시점을 관찰할 수 있지만 내용을 읽을 수는 없습니다. 기기가 가져오는 모든 객체는 데이터베이스에 닿기 전에 서명과 구성원 자격을 검증합니다. 저장소는 신뢰할 수 없는 수동 우편함입니다. 암호화와 신원과 구성원을 보세요.