Генерация UUID для ключей IndexedDB?

Question

Спецификация W3C для IndexedDB определяет генератор ключей как:

Генератор ключей генерирует монотонно увеличивающиеся числа [sic] каждый раз, когда требуется ключ.

Теперь мне кажется (для меня), что распространенным вариантом использования IndexedDB (или, в этом отношении, любого из вариантов хранения на стороне клиента HTML5: WebSQL, localStorage и т. Д.) Будут приложения, предназначенные для работы в автономном режиме (в совместно с HTML5 ApplicationCache).

В этом сценарии отключенное веб-приложение может создавать новые объекты / записи в локальном хранилище данных, которые впоследствии синхронизируются с централизованной базой данных, когда становится доступным соединение с сервером.

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

UUID (или GUID) является хорошим выбором, поскольку он позволяет генерировать уникальные ключи без какой-либо центральной координации. Напротив, «монотонно увеличивающиеся числа» - плохое решение (если только каждый клиент не «затравлен» начальным значением, которое вряд ли столкнется с другими пользователями).

Меня удивляет, что спецификация IndexedDB не определяет (или даже не учитывает будущую поддержку) генераторов альтернативных ключей, таких как генератор UUID. Некоторые могут предположить, что ответом будет просто не использовать встроенный генератор ключей IndexedDB, вместо этого пусть ваше приложение генерирует свои собственные ключи.

Однако, хотя существует множество доступных генераторов UUID на основе Javascript, многие из них, похоже, основаны на Math.random (), который имеет известные ограничения с точки зрения случайности , поэтому может не быть хороший выбор, если необходимо гарантировать абсолютные уникальные ключи.

Собственный генератор UUID, предоставляемый разработчиками IndexedDB, (предположительно) будет более устойчивым и будет работать лучше, чем сценарий, реализованный / импортированный приложением; можно подумать.

Итак, я что-то здесь упускаю или это упущенная возможность рабочей группой W3C IndexedDB?

Answer 1

Ключи objectStore должны быть уникальными для objectStore в локальной базе данных и ничего более.Любая семантика более высокого уровня об уникальности действительно выходит за рамки IndexedDB.Вы описываете UUID, но даже это всего лишь одна из форм уникальных ключей.Существует множество способов генерации UUID с разными свойствами, включая определенный префикс в сочетании с монотонно увеличивающимися младшими битами, случайное генерирование всего объекта, определение его по адресу сетевой карты и т. Д.

ВыборомТо, что ограничивается только локальным экземпляром, IDB (к лучшему или к худшему) заставляет разработчиков сделать осторожный выбор в отношении «глобально» уникального ключа.

Answer 2

Это довольно напряженный вопрос, но, если вы хотите, чтобы мои мысли об этом после работы с IndexedDB в течение пары лет, я бы сказал, что UUID API было бы неплохо, но это выходит за рамки того, что пытается рабочая группа достичь.

UUID, одноименно, «универсально» уникален. Самая высокая концепция уникальности в IndexedDB - это хранилище объектов на уровне данных и база данных на уровне браузера.

На практике мне нравится, что я могу получить предсказуемые, воспроизводимые результаты при повторном запуске кода в новой базе данных или хранилище объектов. Хотя я могу видеть ситуации, когда мне хотелось бы поддерживать уникальность для всех клиентских БД, я определенно не хотел бы, чтобы это было по умолчанию.

Мне лично не требуется универсальная уникальность с моими клиентскими базами данных, но, в любом случае, есть отличные реализации UUID JS, если вы это сделаете.