Web SQL Database API, który umożliwia przechowywanie danych w uporządkowany sposób na komputerze użytkownika (wewnętrznie oparty na silniku bazy danych SQLite), został wprowadzony w kwietniu 2009 r. i zastąpiony w listopadzie 2010 r.. Chociaż została ona zaimplementowana w WebKit (który obsługuje Safari) i pozostała aktywna w silniku Blink (który obsługuje Chrome), Gecko (który obsługuje Firefox) nigdy nie wdrożył tej funkcji, a WebKit usunął ją w 2019 r.
World Wide Web Consortium (W3C) zachęca użytkowników, którzy potrzebują internetowych baz danych do wdrożenia technologii Web Storage API, takich jak localStorage czy sessionStorage czy IndexedDB.
Technologie te wykazują swoje mocne strony w przypadku magazynów klucz-wartość oraz uporządkowanych danych, ale mają też swoje mocne strony, np. brak dobrego języka zapytań. Użytkownicy chcą korzystać z SQL w internecie z pewnego powodu.
Wycofanie i usunięcie interfejsu Web SQL
- [ Gotowe.] Usługa Web SQL została wycofana i usunięta z kontekstów innych firm w Chromium 97 (4 stycznia 2022 r.).
- [ Gotowe.] Dostęp do Web SQL w niezabezpieczonych kontekstach został wycofany w dniu Chromium 105 ( 4 stycznia 2022 r. W tym czasie w panelu problemów w Narzędziach deweloperskich w Chrome pojawiał się komunikat ostrzegawczy.
- [ Gotowe.] Od Chromium 110 (4 stycznia 2022 r.) nie można już korzystać z Web SQL w niezabezpieczonych kontekstach. Zasady dotyczące przedsiębiorstwa umożliwiające korzystanie z tej funkcji są dostępne w wersjach od Chromium 110 (4 stycznia 2022 r.) do Chromium 123 (4 stycznia 2022 r.).
- [ Gotowe.] Dostęp do bazy danych WebSQL w wszystkich kontekstach został wycofany w Chromium 115 (4 stycznia 2022 r.). W panelu Problemy w Narzędziach deweloperskich w Chrome wyświetla się ostrzeżenie.
- [ Gotowe.] Okres wycofania z możliwością dalszego używania Web SQL był dostępny od wersji Chromium 117 (4 stycznia 2022 r.) do Chromium 123 (4 stycznia 2022 r.). Więcej informacji o testach wycofywania znajdziesz w artykule Pierwsze kroki z testami pochodzenia.
- [ Gotowe.] Dostęp do bazy danych WebSQL we wszystkich kontekstach nie jest już dostępny od wersji Chromium 119.
Co dalej
Jak wspomniano we wstępie, technologie takie jak Web Storage API (localStorage i sessionStorage) lub standard IndexedDB są dobrymi alternatywami w wielu, ale nie we wszystkich przypadkach.
Uzasadnienie pozostawienia miejsca na dane programistom stron internetowych
Dzięki Wasm rozwiązania SQL lub NoSQL mogą trafić do sieci. Przykładem jest DuckDB-Wasm lub absurd-sql. Na podstawie tych rozwiązań uważamy, że społeczność deweloperów może szybciej i lepiej tworzyć nowe rozwiązania dotyczące przechowywania danych niż dostawcy przeglądarek.
Planujemy nie tylko usunąć Web SQL. Zastąpiliśmy je czymś, co będzie obsługiwane przez społeczność open source i udostępniane jako pakiet, który można aktualizować według potrzeb – bez konieczności wprowadzania poprawek i nowych funkcji bezpośrednio w przeglądarkach. Naszym celem jest umożliwienie deweloperom przeniesienia ich własnej bazy danych do sieci.
Mamy też nadzieję, że ten przykład pomoże w rozwinięciu nowej ekosystemu baz danych typu open source. Dzięki udostępnieniu uchwytów dostępu do systemu plików mamy w końcu nowy element, na którym można budować niestandardowe rozwiązania dotyczące miejsca na dane.
Powody wycofania Web SQL
Kwestie dotyczące zrównoważonego rozwoju i bezpieczeństwa
Specyfikacji Web SQL nie można wdrożyć w sposób trwały, co ogranicza innowacje i nowe funkcje. Ostatnia wersja standardu to dosłownie stany „Klienty użytkownika muszą wdrożyć dialekt SQL obsługiwany przez Sqlite 3.6.19”.
SQLite nie zostało początkowo zaprojektowane do uruchamiania złośliwych instrukcji SQL, ale implementacja Web SQL wymaga od przeglądarek właśnie tego. Aktualizacja SQLite w Chromium jest konieczna ze względu na konieczność wprowadzania poprawek związanych z bezpieczeństwem i stabilnością. Znajduje się to w bezpośredniej sprzeczności z wymaganiami Web SQL, które wymagają zachowania dokładnie tak jak SQLite 3.6.19.
Kształt interfejsu API
Web SQL to też interfejs API, który odzwierciedla swój wiek. Jest to świetny przykład „piekła wywołań zwrotnych”, jak pokazuje poniższy przykładowy kod (udostępniony przez Nolana Lawsona). Jak widać, instrukcje SQL (korzystając z dialektu SQLite) są przekazywane jako ciągi znaków do metod bazy danych.
openDatabase(
// Name
'mydatabase',
// Version
1,
// Display name
'mydatabase',
// Estimated size
5000000,
// Creation callback
function (db) {
db.transaction(
// Transaction callback
function (tx) {
// Execute SQL statement
tx.executeSql(
// SQL statement
'create table rainstorms (mood text, severity int)',
// Arguments
[],
// Success callback
function () {
// Execute SQL statement
tx.executeSql(
// SQL statement
'insert into rainstorms values (?, ?)',
// Arguments
['somber', 6],
// Success callback
function () {
// Execute SQL statement
tx.executeSql(
// SQL statement
'select * from rainstorms where mood = ?',
// Arguments
['somber'],
// Success callback
function (tx, res) {
// Do something with the result
var row = res.rows.item(0);
console.log(
'rainstorm severity: ' +
row.severity +
', my mood: ' +
row.mood,
);
},
);
},
);
},
);
},
// Error callback
function (err) {
console.log('Transaction failed!: ' + err);
},
// Success callback);
function () {
console.log('Transaction succeeded!');
},
);
},
);
Jeśli uruchomisz ten kod i sprawdzisz utworzoną tabelę za pomocą Narzędzi deweloperskich w Chrome, otrzymasz taki wynik:
Brak obsługi implementatora
Oprócz tajemniczego kształtu interfejsu API (przynajmniej z dzisiejszego punktu widzenia) Mozilla miała wiele wątpliwości związanych z tworzeniem Web SQL na bazie SQLite:
„Nie uważamy, że [SQLite] jest odpowiednią podstawą interfejsu API udostępnianego do ogólnych treści internetowych, między innymi dlatego, że nie ma wiarygodnego, powszechnie akceptowanego standardu, który w przydatny sposób poddaje SQL podzbiór. Nie chcemy też, aby zmiany w SQLite wpływały później na działanie internetu, i nie uważamy, że korzystanie z SQLite w przypadku wersji głównych przeglądarek (i standardu internetowego) jest rozsądne”.
O obawieniach Mozilli możesz przeczytać w poście na blogu Vladimira Vukićevicia, byłego pracownika Mozilli. Więcej historii znajdziesz w minutach grupy roboczej W3C Web Applications (a jeśli chcesz poznać więcej szczegółów, przeczytaj dzienniki IRC) i archiwa list adresowych. Co się stało, warto też przeczytać Post na blogu Nolana Lawsona.
Prześlij opinię
Jeśli masz jakiekolwiek wątpliwości dotyczące kroków wycofywania opisanych w tym poście, daj nam znać na liście mailingowej blink-dev. Członkostwo w tej grupie jest dostępne dla każdego i każdy może zamieszczać posty.
Powiązane artykuły
- Wpis w ChromeStatus: Wycofanie i usunięcie WebSQL w kontekście rozwiązań zewnętrznych
- Wpis w ChromeStatus: Wycofanie i usunięcie bazy danych WebSQL w niezabezpieczonym kontekście
- Intencja dotycząca wycofywania i usuwania: WebSQL w kontekście rozwiązań zewnętrznych
- Planowane wycofanie i usunięcie: WebSQL w niezabezpieczonych kontekstach
- Problem z Chromium: wycofanie i usunięcie bazy danych WebSQL w kontekście rozwiązań zewnętrznych
- Problem z Chromium: wycofanie i usunięcie bazy danych WebSQL w niezabezpieczonym kontekście
- Problem w Chromium: Wycofaj i usuń bazę danych WebSQL (Window#openDatabase)
- SQLite Wasm w przeglądarce z wykorzystaniem prywatnego systemu plików Origin
Podziękowania
Ten artykuł został sprawdzony przez Joe Medleya i Bena Morssa oraz Joshuę Bella.