Interfejs Web SQL Database API, który pozwala przechowywać dane w uporządkowany sposób na komputerze użytkownika (wewnętrznie oparty na silniku bazy danych SQLite), został wprowadzony w kwietniu 2009 r. i został wycofany w listopadzie 2010 roku. Chociaż została ona wdrożona w WebKit (na której opiera się Safari) i pozostała aktywna w silniku Blink (na którym działa Chrome), Gecko (na której działa Firefox) nigdy nie wdrożył tej funkcji i w 2019 roku ją usunęła.
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ń. Nie bez powodu ludzie potrzebują SQL w internecie.
Kroki wycofywania i usuwania 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 firmowe umożliwiające dalsze korzystanie z tej funkcji są dostępne w Chromium 110 ( 4 stycznia 2022 r. w Chromium 123 ( 4 stycznia 2022 r.
- [ Gotowe.] Dostęp do Web SQL we wszystkich kontekstach został wycofany w Chromium 115 (4 stycznia 2022 r.), a w panelu problemów w Narzędziach deweloperskich w Chrome jest wyświetlane ostrzeżenie.
- [ Gotowe.] W Chromium 117 (w wersji 4 stycznia 2022 r.) w Chromium 123 (4 stycznia 2022 r.) udostępniliśmy wersję próbną wycofywania, która umożliwia dalsze korzystanie z Web SQL. Więcej informacji o testach wycofania znajdziesz w artykule Pierwsze kroki z testami origin.
- [ Gotowe.] Dostęp do Web SQL we wszystkich kontekstach nie jest już możliwy w Chromium 119.
Co dalej
Jak wspomnieliśmy na wstępie, technologie Web Storage API, takie jak localStorage i sessionStorage czy standard IndexedDB, są dobrymi alternatywami w wielu, ale nie we wszystkich przypadkach.
Uzasadnienie pozostawienia miejsca na dane deweloperom stron internetowych
Wraz z nadejściem rozwiązań Wasm, SQL i NoSQL mogą pojawić się w internecie. Przykładami są DuckDB-Wasm i absurd-sql. Uważamy, że społeczność programistów może tworzyć nowe rozwiązania szybciej i lepiej niż dostawcy przeglądarek.
Planujemy nie tylko usunąć Web SQL. Zastąpiliśmy ją elementem, który będzie wykorzystywany przez społeczność open source. Będzie stanowił pakiet, który można dowolnie aktualizować bez konieczności wprowadzania poprawek i nowych funkcji bezpośrednio w przeglądarkach. Naszym celem jest umożliwienie programistom udostępniania w internecie własnych baz danych.
Mamy też nadzieję, że ten przykład pomoże w rozwoju nowego ekosystemu baz danych open source. Wraz z wprowadzeniem nicków dostępu do systemu plików udostępnimy nowy obiekt podstawowy, na którym można tworzyć niestandardowe rozwiązania do przechowywania danych.
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 zrównoważony, co ogranicza innowacyjność 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”.
Usługa SQLite nie była początkowo zaprojektowana do uruchamiania złośliwych instrukcji SQL, ale wdrożenie Web SQL oznacza, że przeglądarki muszą robić to właśnie tak. Aktualizacja SQLite w Chromium jest uzależniona od konieczności stosowania poprawek dotyczących bezpieczeństwa 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 także interfejs API, który pokazuje jego wiek. Dla dziecka końca 2000 r. jest to świetny przykład „odwrotnego piekła”, co demonstruje ten przykładowy kod (z uprzejmości Nolana Lawsona). Jak widać, instrukcje SQL (z użyciem 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, efekt będzie wyglądał tak:
Brak pomocy we wdrażaniu
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:
„Uważamy, że [SQLite] nie jest odpowiednią podstawą dla interfejsu API dostępnego dla ogólnych treści z internetu, zwłaszcza dlatego, że nie ma wiarygodnego i powszechnie akceptowanego standardu, który stanowiłby przydatny podzbiorów SQL. Ponadto nie chcemy, aby zmiany w SQLite wpłynęły później na sieć i nie uważamy wykorzystywania w SQLite najważniejszych wersji przeglądarek (i standardu internetowego)”.
Więcej o zastrzeżeniach Mozilli przeczytasz w poście na blogu Mozillan Vladimir Vukićevića. 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 jakieś wątpliwości dotyczące kroków wycofywania opisanych w tym poście, daj nam znać, korzystając z listy adresowej 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 ChromeStatus: Wycofywanie i usuwanie bazy danych WebSQL w kontekście rozwiązań zewnętrznych
- Wpis ChromeStatus: Wycofywanie i usuwanie bazy danych WebSQL w niezabezpieczonych kontekstach
- Zamiar wycofania i usunięcia: WebSQL w kontekście rozwiązań zewnętrznych
- Zamiar wycofania i usunięcia: WebSQL w niezabezpieczonych kontekstach
- Problem z Chromium: Wycofywanie i usuwanie bazy danych WebSQL w kontekście rozwiązań zewnętrznych
- Problem z Chromium: Wycofywanie i usuwanie bazy danych WebSQL w niezabezpieczonych kontekstach
- Problem w Chromium: Wycofaj i usuń bazę danych WebSQL (Window#openDatabase)
- SQLite Wasm w przeglądarce opartym na Origin Private File System
Podziękowania
Ten artykuł napisali Joe Medley, Ben Morss i Joshua Bell.