Sync

bae નું sync coven નું sync છે: bae પોતાની tables અને blobs declare કરે છે, અને coven બાકીનું કરે છે. આ page bae પર લાગુ પડે તે mechanics છે; coven ના પોતાના docs દરેક ભાગ વધારે ઊંડાઈમાં આવરે છે.

Capture

coven SQLite connection નું માલિક છે, તેથી bae commit કરે તે દરેક write તેના મારફતે જાય છે. Sync થતાં tables બદલતો transaction commit થાય ત્યારે coven એ જ transaction માં દરેક હરોળનો ફેરફાર, તેણે સ્પર્શેલી columns સાથે, નોંધે છે, તેથી commit થયેલો ફેરફાર ક્યારેય ખોવાતો નથી, app એક ક્ષણ પછી crash થાય તો પણ. Diffing નહીં, dirty flags નહીં: capture connection નો ગુણધર્મ છે, અને write ચૂકી શકાતું નથી. ફેરફાર ઉપકરણ પર રાહ જુએ છે અને મોકલતી વખતે જ encrypt અને સહી થાય છે, તેથી લખવા માટે key કે network ની જરૂર નથી.

ક્રમ

Cloud home માં લાઇબ્રેરીનો આખો ઇતિહાસ objects નો એક ક્રમાંકિત ક્રમ છે. દરેકમાં એક ઉપકરણના ફેરફારોનો સમૂહ, એક admin entry, એક સભ્ય માટે seal કરેલી key, અથવા snapshot ની જાહેરાત હોય છે. દરેક ઉપકરણ તેમને ક્રમમાં લાગુ કરે છે અને કોઈ છોડતું નથી, તેથી બધાં ઉપકરણો સંમત થાય છે કે શું અને ક્યારે થયું. ઉપકરણ પહેલાંના બધા લાગુ કર્યા પછી જ આગળનો object ઉમેરે છે.

એક sync pass ઉપકરણે છેલ્લે લાગુ કરેલા object થી આગળ વાંચે છે જ્યાં સુધી કોઈ ખૂટતો ન મળે, દરેકની સહી ચકાસીને લાગુ કરે છે, આ ઉપકરણના કતારમાંના ફેરફારો એક નવા object તરીકે મોકલે છે, પછી નવી સ્થિતિ માંગે તે કામ કરે છે: પહોંચ શેર કરવી કે દૂર કરવી, snapshots લેવા, જૂનો ઇતિહાસ કાઢવો. શાંત લાઇબ્રેરી પર એક pass બે વિનંતીઓ લે છે, તેનું કદ ગમે તે હોય.

Passes સ્થાનિક ફેરફારો પછી, idle timer પર, અને Sync Now પર તરત ચાલે છે. નિષ્ફળતાઓ એક જ backoff યોજનાથી ફરી પ્રયાસ કરે છે, અને જે આગળ વધી ન શકે તે કહે છે કે તે શાની રાહ જુએ છે, જે bae પોતાની sync સ્થિતિ લીટીમાં બતાવે છે.

Merge

બે devices અલગ હોય ત્યારે એ જ library edit કરે તે normal case છે, exception નહીં. તેમના changes મળે ત્યારે:

• જુદા rows અથવા જુદા columns પર edits બંને apply થાય છે. Laptop પર release નું year edit કરવું અને desktop પર તેનું label edit કરવું બંને yields કરે છે.
• એ જ હરોળની એ જ column પરનાં સંપાદનો timestamp પ્રમાણે ક્રમમાં ગોઠવાય છે: પછીનું સંપાદન જીતે છે, નિશ્ચિત રીતે અને દરેક ઉપકરણ પર સરખી રીતે.
• સાથે થયેલાં સંપાદનો પર delete જીતે છે: પછીથી કાઢી નખાયેલી હરોળ પર કરેલું સંપાદન ગમે ત્યારે પહોંચે, હારે છે, તેથી એક ઉપકરણ પર કાઢેલો release કાઢેલો જ રહે છે, ભલે બીજા ઉપકરણે એ જ સમયગાળામાં તેને સંપાદિત કર્યો હોય.

coven દરેક બદલાયેલા મૂલ્યને ખોવાયેલું મૂલ્ય તરીકે રાખે છે; bae તેમાંથી કોઈ બતાવતું નથી કે કાઢતું નથી, તેથી conflict UI નથી. પહોંચવાનો ક્રમ ગમે તે હોય, દરેક ઉપકરણ એ જ પરિણામ પર પહોંચે છે.

સ્નેપશોટ

જોડાતું કે પુનઃસ્થાપિત થતું ઉપકરણ ઇતિહાસ શરૂઆતથી replay કરતું નથી. ઉપકરણો snapshots લે છે, એટલે કે ક્રમના એક બિંદુએ લાઇબ્રેરીની પૂર્ણ સ્થિતિ, અને લાઇબ્રેરી તથા દરેક ખાનગી circle પાસે એક થઈ જાય પછી તેની પહેલાંનો ઇતિહાસ કાઢી નખાય છે. નવું ઉપકરણ સૌથી નવો snapshot લોડ કરે છે, પછી ફક્ત તેના પછી આવેલું લાગુ કરે છે. રાખેલા ઇતિહાસ કરતાં લાંબો સમય દૂર રહેલું ઉપકરણ પણ આમ જ કરે છે, અને પોતાનાં ન મોકલાયેલાં સંપાદનો રાખે છે.

Schema versions

bae નો schema એક જ migration છે, અને ઉપકરણ મોકલે તે દરેક ફેરફાર તે જે schema version થી બન્યો તે નોંધે છે. પોતાના કરતાં નવા schema ના ફેરફાર સુધી પહોંચતું ઉપકરણ ત્યાં જ અટકે છે, app update ન થાય ત્યાં સુધી તેની પછી કશું લાગુ કરતું નથી; કશું ખોવાતું નથી અને કશું ખોટું લાગુ થતું નથી.

Schema version કરતાં coarser compatibility era છે: દરેક binary માં baked pinned coven revision. બે builds ફક્ત એક era અંદર sync કરે છે; coven wire-format break એ new era અને દરેક app પર major version bump છે. Pre-1.0, દરેક build era zero છે અને formats migration વગર બદલાય છે.

Provider શું જુએ છે

પ્રદાતા encrypted ફેરફારો, snapshots, સભ્યપદ records અને files રાખે છે; તે objects ગણી શકે છે, કદ અને સમય જોઈ શકે છે, અને કયું ખાતું દરેક object લખે છે તે જોઈ શકે છે, પણ વિષયવસ્તુમાંથી કશું વાંચી શકતો નથી. ઉપકરણ લાવે તે દરેક object database ને સ્પર્શે તે પહેલાં સહી અને સભ્યપદ બંનેથી ચકાસાય છે: સ્ટોરેજ એક નિષ્ક્રિય, અવિશ્વસનીય ટપાલપેટી છે. Encryption અને ઓળખ અને સભ્યપદ જુઓ.