منسوخ کردن و حذف Web SQL

توماس اشتاینر

Web SQL Database API که به شما امکان می‌دهد داده‌ها را به روشی ساختاریافته بر روی رایانه کاربر (به صورت داخلی بر اساس موتور پایگاه داده SQLite) ذخیره کنید، در آوریل 2009 معرفی شد و در نوامبر 2010 کنار گذاشته شد . در حالی که در WebKit (که سافاری را قدرت می‌دهد) پیاده‌سازی شد و در موتور Blink (که کروم را تامین می‌کند) فعال باقی ماند، Gecko (که فایرفاکس را تامین می‌کند) هرگز این ویژگی را پیاده‌سازی نکرد و WebKit آن را در سال 2019 حذف کرد .

کنسرسیوم وب جهانی (W3C) کسانی را که به پایگاه‌های داده وب نیاز دارند تشویق می‌کند تا از فناوری‌های Web Storage API مانند localStorage و sessionStorage یا IndexedDB استفاده کنند. این فناوری‌ها نقاط قوت خود را در مورد ذخیره‌های کلید/ارزش و داده‌های ساختاریافته نشان می‌دهند، اما مسلماً نقاط ضعفی مانند فقدان یک زبان پرس و جو قوی نیز دارند. مردم به دلایلی SQL را در وب می خواهند.

مراحل حذف و منسوخ شدن وب SQL

  • [ Done.] Web SQL منسوخ شد و برای زمینه های شخص ثالث در Chromium 97 (4 ژانویه 2022) حذف شد.
  • [ انجام شد.] دسترسی SQL وب در زمینه‌های ناامن از Chromium 105 (4 ژانویه 2022) منسوخ شد و در آن زمان یک پیام هشدار در پانل مشکل ابزارهای برنامه‌نویس Chrome نشان داده شد.

پانل مشکلات Chrome DevTools با اخطاری که Web SQL را در زمینه های غیر ایمن می خواند منسوخ شده است.

  • [ انجام شد.] دسترسی وب SQL در زمینه‌های ناامن دیگر از Chromium 110 (4 ژانویه 2022) در دسترس نیست. خط مشی سازمانی برای ادامه استفاده از این ویژگی از Chromium 110 (4 ژانویه 2022) تا Chromium 123 (4 ژانویه 2022) در دسترس است.
  • [ انجام شد.] دسترسی به وب SQL در همه زمینه‌ها از Chromium 115 (4 ژانویه 2022) منسوخ شده است و یک پیام هشدار در پانل مشکل ابزارهای توسعه‌دهنده Chrome نشان داده می‌شود.
  • [ انجام شد.] آزمایشی منسوخ برای ادامه استفاده از Web SQL از Chromium 117 (4 ژانویه 2022) تا Chromium 123 (4 ژانویه 2022) در دسترس بود. برای کسب اطلاعات بیشتر در مورد آزمایش‌های منسوخ، به شروع کار با آزمایش‌های مبدأ مراجعه کنید.
  • [ Done.] دسترسی به وب SQL در همه زمینه‌ها دیگر از Chromium 119 در دسترس نیست.

از اینجا به کجا برویم

همانطور که در مقدمه اشاره شد، فناوری‌های Web Storage API مانند localStorage و sessionStorage یا استاندارد IndexedDB در بسیاری موارد جایگزین خوبی هستند، اما نه همه موارد.

دلیل واگذاری فضای ذخیره سازی به توسعه دهندگان وب

با ظهور Wasm، راه حل های SQL یا NoSQL می توانند به وب بیایند. یک مثال DuckDB-Wasm و دیگری absurd-sql است. بر اساس این خلاقیت‌ها، ما احساس می‌کنیم که جامعه توسعه‌دهنده می‌تواند راه‌حل‌های ذخیره‌سازی جدید را سریع‌تر و بهتر از فروشندگان مرورگر تکرار کرده و ایجاد کند.

ما قصد نداریم فقط وب SQL را حذف کنیم. در واقع، ما آن را با چیزی جایگزین کردیم که توسط جامعه منبع باز نگهداری می‌شود، به عنوان بسته‌ای که می‌تواند به دلخواه به‌روزرسانی شود—بدون بار معرفی اصلاحات و ویژگی‌های جدید مستقیماً در مرورگرها. هدف ما واقعاً این است که به توسعه دهندگان اجازه دهیم پایگاه داده خود را به وب بیاورند.

علاوه بر این، ما امیدواریم که این مثال به شکوفایی اکوسیستم جدیدی از پایگاه های داده منبع باز کمک کند! انتشار دستگیره‌های دسترسی به سیستم فایل در نهایت اولیه جدیدی را فراهم می‌کند که راه‌حل‌های ذخیره‌سازی سفارشی را می‌توان بر اساس آن ساخت.

دلایل منسوخ شدن وب SQL

نگرانی های پایداری و امنیتی

مشخصات Web SQL را نمی توان به طور پایدار پیاده سازی کرد، که نوآوری و ویژگی های جدید را محدود می کند. آخرین نسخه استاندارد به معنای واقعی کلمه می‌گوید: «عامل‌های کاربر باید گویش SQL پشتیبانی شده توسط Sqlite 3.6.19 را پیاده‌سازی کنند» .

SQLite در ابتدا برای اجرای دستورات SQL مخرب طراحی نشده بود، اما پیاده سازی Web SQL به این معنی است که مرورگرها باید دقیقاً این کار را انجام دهند. نیاز به همگام شدن با اصلاحات امنیتی و پایداری، به‌روزرسانی SQLite را در Chromium دیکته می‌کند. این در تضاد مستقیم با الزامات Web SQL برای رفتار دقیقاً مانند SQLite 3.6.19 است.

شکل API

Web SQL نیز یک API است که سن آن را نشان می دهد. همانطور که نمونه کد زیر ( با حسن نیت از نولان لاوسون ) نشان می دهد، به عنوان فرزند اواخر دهه 2000، مثال عالی از "جهنم پاسخ به تماس" است. همانطور که می بینید، دستورات SQL (با استفاده از گویش SQLite SQL) به عنوان رشته به متدهای پایگاه داده ارسال می شوند.

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!');
      },
    );
  },
);

اگر قرار بود این کد را اجرا کنید و جدول ایجاد شده را با Chrome DevTools بررسی کنید ، نتیجه این است:

بررسی بخش Web SQL در Chrome DevTools پایگاه داده‌ای به نام mydatabase را با جدولی به نام rainstorms با حالت ستون‌ها (متن) و شدت (عدد صحیح) نشان می‌دهد که دارای یک ورودی با حالت غم انگیز و شدت شش است.

عدم پشتیبانی مجری

جدا از شکل مخفی API (حداقل از دیدگاه امروزی)، موزیلا نگرانی های زیادی در مورد ساخت وب SQL بر اساس SQLite داشت:

ما فکر نمی‌کنیم [SQLite] مبنای مناسبی برای یک API باشد که در معرض محتوای عمومی وب قرار می‌گیرد، مهم‌تر از همه به این دلیل که استاندارد معتبر و پذیرفته‌شده‌ای وجود ندارد که SQL را به روشی مفید زیرمجموعه‌بندی کند. نمی‌خواهید تغییرات در SQLite بعداً روی وب تأثیر بگذارد، و فکر نکنید استفاده از نسخه‌های اصلی مرورگر (و یک استاندارد وب) برای SQLite عاقلانه است."

می‌توانید در مورد نگرانی‌های موزیلا در پست وبلاگ ولادیمیر ووکیچویچ سابق موزیلان بخوانید. برای اطلاعات بیشتر، دقایق گروه کاری برنامه های کاربردی وب W3C را بررسی کنید (و اگر واقعاً می خواهید وارد جزئیات شوید، گزارش های IRC را بخوانید) و بایگانی لیست پستی ). علاوه بر این، پست وبلاگ نولان لاوسون نمای کلی خوبی از آنچه اتفاق افتاده است ارائه می دهد.

بازخورد

اگر در مورد مراحل منسوخ شده در این پست نگرانی دارید، در لیست پستی blink-dev به ما اطلاع دهید. عضویت در این گروه برای همه آزاد است و هر کسی مجاز به ارسال پست است.

قدردانی ها

این مقاله توسط جو مدلی و بن مورس و جاشوا بل بررسی شده است.