Параметр version: версия базы данных

Версия базы данных в контексте localForage напрямую не представлена как отдельный параметр конфигурации API. В отличие от «классического» IndexedDB, где версия базы данных является частью встроенного механизма миграций схемы, localForage абстрагирует низкоуровневую работу и не предоставляет явного поля version в config. Понимание версии в этой библиотеке требует рассмотрения того, как устроено хранилище под капотом и какие стратегии используются для изменения структуры данных.

localForage может использовать несколько драйверов хранения, включая IndexedDB, WebSQL (устаревший) и localStorage. Наиболее важным с точки зрения версии является IndexedDB.

В IndexedDB:

  • каждая база данных имеет номер версии
  • изменение структуры объектов требует увеличения версии
  • при изменении версии вызывается событие onupgradeneeded
  • именно здесь создаются или модифицируются object store

Пример логики IndexedDB:

const request = indexedDB.open("appDB", 2);

request.onupgradenee ded = (event) => {
  const db = event.target.result;

  if (!db.objectStoreNames.contains("users")) {
    db.createObjectStore("users");
  }
};

localForage скрывает этот механизм и управляет объектным хранилищем автоматически, не предоставляя прямого контроля над числом версии базы данных.

Почему в localForage отсутствует параметр version

Архитектура localForage ориентирована на упрощение работы с клиентским хранилищем:

  • единый API поверх разных движков хранения
  • отсутствие необходимости вручную управлять миграциями IndexedDB
  • автоматическое создание store при первом обращении
  • изоляция от низкоуровневых деталей реализации браузера

Поскольку WebSQL и localStorage не имеют понятия версии базы данных, введение универсального параметра version в конфигурацию нарушило бы кросс-драйверную модель библиотеки.

Логическая «версия» через name и storeName

Хотя явного параметра версии нет, в localForage используется косвенная модель управления схемой через:

  • name — имя базы данных
  • storeName — имя хранилища (object store)

Изменение этих параметров фактически создаёт новую «логическую версию» структуры данных.

Пример конфигурации

import localforage from "localforage";

localforage.config({
  name: "app_v2",
  storeName: "users_store"
});

Изменение name или storeName приводит к созданию новой изолированной области хранения, что по сути эквивалентно переходу на новую версию схемы.

Множественные экземпляры как механизм версионирования

localForage поддерживает создание независимых экземпляров через createInstance. Это позволяет реализовывать версионность вручную.

const v1DB = localforage.createInstance({
  name: "app",
  storeName: "data_v1"
});

const v2DB = localforage.createInstance({
  name: "app",
  storeName: "data_v2"
});

Такой подход используется для:

  • постепенной миграции данных
  • параллельной поддержки старой и новой структуры
  • безопасного обновления без потери данных

Эмуляция миграций данных

Поскольку автоматического механизма миграций нет, версия данных часто реализуется вручную на уровне приложения.

Типичная стратегия:

  1. хранение текущей версии схемы в отдельном ключе
  2. проверка версии при запуске
  3. выполнение миграционных скриптов

Пример хранения версии

await localforage.setItem("schema_version", 2);

Проверка версии

const version = await localforage.getItem("schema_version");

if (version === 1) {
  // миграция данных в новую структуру
}

Особенности поведения при смене структуры данных

Изменение структуры данных без контроля версии может приводить к следующим последствиям:

  • старые ключи остаются в хранилище
  • новые данные записываются в обновлённом формате
  • отсутствует автоматическая конвертация объектов
  • возможны конфликты логики чтения

localForage не выполняет:

  • трансформацию существующих записей
  • удаление устаревших ключей
  • синхронизацию структур между версиями

Эти операции полностью остаются на стороне разработчика.

Связь с IndexedDB version внутри драйвера

Хотя библиотека не экспонирует version, внутри IndexedDB-драйвера версия базы всё же существует и управляется автоматически.

При первом создании хранилища localForage:

  • открывает IndexedDB с версией 1
  • создаёт object store с именем storeName
  • при последующих изменениях структуры может переоткрывать соединение

Однако увеличение версии базы происходит неявно и не предназначено для прямого использования.

Изоляция версий через разные базы

Практическим способом управления «версиями» является создание отдельных баз данных через изменение name.

const db_v1 = localforage.createInstance({
  name: "analytics_v1"
});

const db_v2 = localforage.createInstance({
  name: "analytics_v2"
});

Такой подход обеспечивает:

  • полную изоляцию данных
  • отсутствие конфликтов схем
  • простоту отката к старой версии

Ограничения отсутствия version-параметра

Отсутствие явного параметра версии приводит к ряду архитектурных особенностей:

  • невозможность декларативных миграций
  • отсутствие встроенного schema manager
  • необходимость ручного контроля структуры
  • зависимость логики обновлений от кода приложения

При этом достигается:

  • кросс-драйверная унификация API
  • минимализм конфигурации
  • стабильность поведения между браузерами

Практическая модель версионирования данных

На уровне проектирования localForage чаще всего используется следующая модель:

  • name — идентификатор приложения или модуля
  • storeName — логическая область данных
  • schema_version — версия структуры данных внутри значений

Такая комбинация заменяет классическую систему версий IndexedDB и обеспечивает управляемую эволюцию хранилища без участия низкоуровневого API браузера.

Оглавление