Wycofanie i usunięcie Web SQL

Thomas Steiner

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.

Konsorcjum W3C (W3C) zachęca użytkowników baz danych internetowych do korzystania z technologii Web Storage API, takich jak localStorage i sessionStorage lub IndexedDB. Te technologie sprawdzają się w przypadku magazynów kluczy-wartości i uporządkowanych danych, ale mają też słabe strony, np. brak mocnego języka zapytań. Użytkownicy chcą korzystać z SQL w internecie z pewnego powodu.

Wycofanie i usunięcie interfejsu Web SQL

  • [ Gotowe.] Baza danych WebSQL została wycofana i usunięta w kontekście rozwiązań zewnętrznych w Chromium 97 (4 stycznia 2022 r.).
  • [ Gotowe.] Dostęp do bazy danych WebSQL w niezabezpieczonych kontekstach został wycofany w Chromium 105 (4 stycznia 2022 r.). W tym czasie w panelu Problemy w Narzędziach deweloperskich w Chrome wyświetlano komunikat z ostrzeżeniem.

Panel Problemy w Narzędziach deweloperskich Chrome z ostrzeżeniem o bazie danych WebSQL w niezabezpieczonych kontekstach jest wycofany.

  • [ Gotowe.] Dostęp do bazy danych WebSQL w niezabezpieczonych kontekstach nie jest już dostępny od wersji Chromium 110 (4 stycznia 2022 r.). 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 i 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.

Nie planujemy usunąć tylko bazy danych 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 interfejsu Web SQL

Zagadnienia związane ze zrównoważonym rozwojem i bezpieczeństwem

Specyfikacji Web SQL nie można wdrożyć w sposób trwały, co ogranicza innowacje i nowe funkcje. Ostatnia wersja standardu dosłownie oświadcza: „Klienci użytkownika muszą implementować 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ą. Jest to w prostej sprzeczności z wymogiem Web SQL, który wymaga działania dokładnie tak samo 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:

W sekcji Web SQL w Narzędziach deweloperskich w Chrome widać bazę danych o nazwie mydatabase z tabelą rainstorms z kolumnami mood (tekstowe) i severity (liczbowe), która zawiera 1 rekord z wartością mood = somber i severity = 6.

Brak pomocy dla implementatorów

Oprócz niejasnego kształtu interfejsu API (przynajmniej z obecnego punktu widzenia) Mozilla miała wiele wątpliwości dotyczących interfejsu Web SQL opartego na 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 podziałowi. 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 sprzedanego pracownika Mozilli Vladimira Vukićevića. Więcej informacji znajdziesz w protokołach W3C Web Applications Working Group (a jeśli naprawdę chcesz poznać szczegóły, przeczytaj logi IRC) i archiwach listy mailingowej. Dodatkowo w poście na blogu Nolana Lawsona znajdziesz dobry przegląd tego, co się stało.

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. Każdy może dołączyć do tej grupy i publikować w niej treści.

Podziękowania

Ten artykuł został sprawdzony przez Joe Medleya i Bena Morssa oraz Joshuę Bella.