Interfejs 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 został porzucony w listopadzie 2010 r. Chociaż zostało zaimplementowane w WebKit (który obsługuje Safari) i pozostało aktywne w silniku Blink (który obsługuje Chrome), firma Gecko (która działa w przeglądarce Firefox) nigdy jej nie wdrożyła, a WebKit usunął ją w 2019 r.
Organizacja World Wide Web Consortium (W3C) zachęca tych korzystających z internetowych baz danych do wdrożenia technologii Web Storage API, takich jak localStorage czy sessionStorage czy IndexedDB.
Technologie te pokazują swoje mocne strony w przypadku magazynów klucz-wartość i uporządkowanych danych, ale trzeba też potwierdzić słabe dane, takie jak brak silnego języka zapytań. Nie bez powodu użytkownicy chcą korzystać z SQL w internecie.
Etapy wycofywania i usuwania Web SQL
- [ Gotowe.] W Chromium 97 (4 stycznia 2022 r.) usługa Web SQL została wycofana i usunięta na potrzeby kontekstów innych firm.
- [ Gotowe.] Dostęp do Web SQL w niezabezpieczonych kontekstach został wycofany od Chromium 105 (4 stycznia 2022 r.). Wtedy w panelu problemów z Narzędziami deweloperskimi w Chrome wyświetlał się komunikat ostrzegawczy.
- [ Gotowe.] Od Chromium 110 (4 stycznia 2022 r.) dostęp do Web SQL w niezabezpieczonych kontekstach nie jest już możliwy. Zasady firmy pozwalające zachować możliwość korzystania z tej funkcji są dostępne od Chromium 110 (od 4 stycznia 2022 r.) do Chromium 123 (4 stycznia 2022 r.).
- [ Gotowe.] Dostęp do Web SQL we wszystkich kontekstach został wycofany od Chromium 115 ( 4 stycznia 2022 r.), a w panelu problemów z Narzędziami deweloperskimi w Chrome pojawia się komunikat ostrzegawczy.
- [ Jesteś tutaj.] Okres próbny wycofania wersji Web SQL jest dostępny od Chromium 117 ( 4 stycznia 2022 r.) do Chromium 123 ( 4 stycznia 2022 r.). Więcej informacji o okresach próbnych wycofywania znajdziesz w artykule Pierwsze kroki z testami origin.
Co dalej
Jak wspomnieliśmy we wstępie, technologie Web Storage API, takie jak localStorage i sessionStorage czy standard IndexedDB, w wielu przypadkach stanowią dobre alternatywne rozwiązania, ale nie wszystkie.
Uzasadnienie pozostawienia miejsca na dane deweloperom stron internetowych
Wraz z nadejściem Wasm rozwiązania SQL i NoSQL pojawiły się w internecie. Jednym z nich jest DuckDB-Wasm, a inny absurd-sql. W wyniku tych zmian uważamy, że społeczność programistów może tworzyć i iterować nowe rozwiązania w zakresie pamięci masowej szybciej i lepiej niż dostawcy przeglądarek.
Nie planujemy tylko usunięcia usługi Web SQL. Zastąpiliśmy ją elementem, który będzie utrzymywany przez społeczność open source i udostępnimy w formie pakietu, 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łasnej bazy danych.
Mamy też nadzieję, że ten przykład pomoże rozwijać ekosystem baz danych typu open source. Udostępnienie uchwytów dostępu do systemu plików stanowi na koniec nowy element podstawowy, na którym można tworzyć niestandardowe rozwiązania do przechowywania danych.
Powody wycofania Web SQL
Kwestie związane ze zrównoważonym rozwojem i bezpieczeństwem
specyfikacji Web SQL nie można wdrażać w sposób zrównoważony, co ogranicza innowacyjność i nowe funkcje. Ostatnia wersja standardu to stany „Klienty użytkownika muszą implementować dialekt SQL obsługiwany przez Sqlite 3.6.19”.
Oprogramowanie SQLite nie zostało początkowo zaprojektowane do uruchamiania złośliwych instrukcji SQL, ale wdrożenie Web SQL oznacza, że właśnie tak będą musiały robić przeglądarki. Konieczność stosowania poprawek w zabezpieczeniach i stabilności wymusza aktualizowanie SQLite w Chromium. Jest to w sposób bezpośredni sprzeczny z wymaganiami Web SQL, które wymagają działania dokładnie tak, jak SQLite 3.6.19.
Kształt interfejsu API
Web SQL to również interfejs API, który pokazuje swój wiek. Jako dziecko pod koniec pierwszej dekady XXI wieku jest to świetny przykład „oddzwaniania do piekła”, co pokazuje ten przykładowy kod (dzięki uprzejmości Nolana Lawsona). Jak widać, instrukcje SQL (z użyciem dialektu SQL 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 spróbujesz uruchomić ten kod i sprawdzić utworzoną tabelę za pomocą Narzędzi deweloperskich w Chrome, uzyskasz taki wynik:
Brak pomocy w zakresie implementacji
Oprócz kształtu interfejsu Arcane API (przynajmniej z dzisiejszego punktu widzenia) Mozilla miała wiele wątp o tworzenie Web SQL na bazie SQLite:
„Uważamy, że [SQLite] nie jest odpowiednią podstawą dla interfejsu API ujawniającego ogólne treści internetowe – nie jest to przede wszystkim dlatego, że nie ma wiarygodnego, powszechnie akceptowanego standardu, który umożliwiałby stosowanie podzbiorów SQL w użyteczny sposób. Nie chcemy też, aby zmiany w SQLite wpływają na działanie sieci w późniejszym czasie, i nie uważamy, że wykorzystywanie głównych wersji przeglądarek (i standardu internetowego) do SQLite jest rozsądne”.
O wątpliwościach Mozilli przeczytasz w tym poście na blogu Mozillan Vladimir Vukićevića. Jeśli chcesz dowiedzieć się więcej na ten temat, sprawdź minuty na grupie roboczej W3C Web Applications (w języku angielskim). Jeśli chcesz dowiedzieć się więcej, przeczytaj dzienniki IRC oraz archiwum list adresowych. Ogólne informacje o tym, co się wydarzyło, znajdziesz też w poście na blogu Nolana Lawsona.
Prześlij opinię
Jeśli masz jakieś wątpliwości związane z opisanymi w tym poście procesami wycofywania, 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 narzędzi innych firm
- 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 narzędzi innych firm
- Problem z Chromium: Wycofanie i usuwanie niezabezpieczonych kontekstów WebSQL
- Problem z Chromium: Wycofywanie i usuwanie bazy danych WebSQL (Window#openDatabase)
- SQLite Wasm w przeglądarce korzystający z prywatnego systemu plików źródła
Podziękowania
Ten artykuł napisali Joe Medley, Ben Morss i Joshua Bell.