SQLite SAHPool cere un plan de revenire pentru stocarea din browser
SQLite 3.50 a schimbat tratarea numelor în SAHPool. Verificați accesul clienților vechi și restaurarea separat de compatibilitatea fișierelor bazei de date.
De 
Paul. Arhitectură și infrastructură
O aplicație din browser poate păstra formatul SQLite al bazei de date și totuși să facă datele stocate inaccesibile unei versiuni mai vechi a aplicației. Schimbarea SAHPool din SQLite 3.50.0 oferă un exemplu concret. Întrebarea operațională este ce versiuni ale clientului mai pot găsi și deschide datele din browser după actualizare, inclusiv după revenirea la versiunea anterioară.
Privind din noiembrie 2026 spre lansarea din mai, lecția utilă pentru mentenanță este să includeți metadatele stocării din browser în contractul de lansare. Compatibilitatea motorului bazei de date nu poate stabili singură acest contract. Echipa are nevoie să identifice adaptorul de stocare, să păstreze date recuperabile și să verifice accesul clientului vechi înainte de a promite o lansare reversibilă.
Notele lansării din 29 mai 2025 identifică remedierea calculului amprentei numelui de fișier în sistemul virtual de fișiere OPFS SAHPool. Ele spun explicit că bazele create acolo de versiunea 3.50.0 sau ulterioară nu pot fi citite de versiuni mai vechi ale acelui VFS, în timp ce 3.50.0 poate lucra cu bazele create anterior. Compatibilitatea are o direcție și un domeniu precis.
Urmăriți nivelurile dintre o înregistrare și stocare
Aplicația execută operațiile bazei de date printr-o interfață și o implementare de stocare. În browser, persistența depinde și de facilitățile browserului, și de modul în care adaptorul asociază numele logice cu obiectele stocate. O bază SQLite validă nu dovedește singură că orice versiune a adaptorului va localiza și interpreta acele obiecte la fel.
Documentația SQLite despre persistența în browser prezintă SAHPool ca una dintre mai multe opțiuni. Este documentație actualizată continuu, consultată pentru această retrospectivă, nu o descriere fixă a fiecărei lansări. Folosiți-o pentru arhitectură și folosiți nota datată a lansării pentru a stabili schimbarea istorică de compatibilitate.
Separarea previne un diagnostic costisitor. Faptul că un client nu mai deschide stocarea după revenire nu dovedește imediat că SQLite a schimbat formatul fișierului sau că aplicația are nevoie de o bază de date pe server. Identificați mai întâi nivelul ale cărui presupuneri s-au schimbat. Înlocuirea motorului ar fi o decizie mult mai amplă decât rezolvarea compatibilității dintre versiunile adaptorului.
Avertismentul nici nu se aplică automat oricărei aplicații SQLite din browser. O aplicație care folosește alt VFS are alt traseu de stocare. O instalare nativă are, la rândul ei, alt mediu. Inventariați pachetul și VFS-ul efectiv livrate, în loc să deduceți expunerea din prezența numelui SQLite între dependențe.
Revenirea codului poate lăsa date noi în urmă
Presupunerea riscantă este că revenirea la un pachet JavaScript anterior readuce întreaga aplicație la starea veche. Datele persistente din browser supraviețuiesc înlocuirii codului. Dacă un client nou creează date pe care vechiul VFS nu le poate citi, simpla selectare a pachetului anterior nu restabilește accesul clientului vechi.
Mai multe mecanisme de livrare pot permite coexistența versiunilor: o filă veche, o resursă din cache sau un utilizator care revine după mult timp. Sunt condiții posibile de investigat, nu afirmația că orice instalare le întâlnește. Echipa ar trebui să stabilească ce versiuni pot opera efectiv asupra aceleiași stocări în aplicația sa.
Direcția contează. Faptul că un client nou deschide o bază veche nu arată dacă un client vechi poate deschide stocarea nou creată. Păstrați verificările separate. O verificare care urmărește doar trecerea înainte poate părea liniștitoare și poate lăsa neexaminată revenirea.
Nu extindeți nota lansării într-o afirmație nesusținută că orice bază veche este imediat rescrisă într-o formă inaccesibilă la primul acces. Avertismentul explicit privește bazele create de VFS-ul mai nou. O afirmație mai puternică despre conversia datelor existente are nevoie de dovezi despre comportamentul adaptorului și versiunea exactă.
Păstrați datele într-o formă care poate fi restaurată
Înaintea unei schimbări importante de stocare, definiți ce conține copia de siguranță și ce versiune a aplicației o poate restaura. Copierea obiectelor stocate și exportul logic al bazei pot servi unor scopuri diferite de recuperare. Alegerea depinde de interfețele acceptate de adaptor și de cerințele de consistență ale aplicației.
O copie de siguranță este utilă numai dacă procedura de restaurare este înțeleasă. Verificarea propusă ar trebui să folosească date reprezentative care pot fi eliminate, să păstreze starea conexă necesară și să redeschidă rezultatul restaurat cu clientul vizat. Simpla prezență a unui fișier într-un director de export nu demonstrează recuperarea. Articolul nu raportează vreun experiment de restaurare sau test în browser.
Separați și restaurarea datelor anterioare de păstrarea lucrului făcut după actualizare. Revenirea la o copie de dinaintea actualizării poate elimina modificările ulterioare. Dacă promiteți revenirea, descrieți cum vor fi tratate acele modificări sau precizați pierderea posibilă înainte ca utilizatorii să depindă de versiunea nouă.
Nu transformați ștergerea stocării browserului în remediul implicit. Aceasta poate elimina singura copie a utilizatorului. Proiectarea recuperării ar trebui să stabilească mai întâi ce se poate exporta, sincroniza sau păstra. Golirea stocării este o decizie distructivă a aplicației, nu un răspuns neutru la un avertisment de compatibilitate.
Instalările cu o singură versiune au o problemă mai restrânsă
Cel mai puternic contraargument este simplitatea operațională. O instalare controlată, care impune o singură versiune și nu revine niciodată la un pachet mai vechi, este mai puțin expusă problemei de citire cu clienți vechi. Poate evita justificat mecanismele necesare unei tranziții lungi cu versiuni coexistente.
Argumentul este solid când presupunerile sale pot fi impuse. Verificați ce se întâmplă cu clienții fără conexiune și dacă revenirea ar reintroduce un cititor vechi. Chiar și instalarea cu o singură versiune are nevoie de recuperare după pierderea datelor sau o lansare eșuată. Riscul mai mic al coexistenței nu dovedește că restaurarea funcționează.
Pentru mentenanță software, cereți o matrice mică de compatibilitate, legată de VFS-ul și versiunile reale. Includeți date vechi cu cititorul nou, date nou create cu cititorul folosit la revenire și procedura acceptată de restaurare. Decizia privește astfel o tranziție precisă a stocării din browser, cu dovezi proporționale riscului, în locul unei dezbateri generale despre înlocuirea SQLite.