Должен ли объект быть написан, чтобы гарантировать, что автоматически назначенные идентификаторы не используются повторно? - PullRequest
2 голосов
/ 15 июня 2019

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

Уникальные автоматически сгенерированные идентификаторы Google Cloud Datastore

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

Я прочитал другие сообщения

При использовании allocateIds (), как долго неиспользуемые идентификаторы остаются распределенными?

и

Являются ли идентификаторы удаленных сущностей снова доступными для App Engine, если они автоматически генерируются для сущности?

но я все еще не уверен. Должен ли я вставить эту фиктивную сущность только с ключом? Если нет, как отслеживаются все выделенные идентификаторы для этого фиктивного объекта и что происходит с соответствующим использованием хранилища?

1 Ответ

1 голос
/ 18 июня 2019

Идентификатор ключа сущности вместе с родом и родом (и, возможно, пространством имен) определяют уникальный ключ сущности, который имеет смысл , даже если сущность на самом деле не существует: возможно иметьдочерние сущности в группе сущностей, привязанной к предку, который не существует.Из путей предков (выделено мной):

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

Таким образом, тот факт, что ваши фиктивные сущностина самом деле существуют или не должны иметь значения: их идентификаторы ключей, предварительно выделенные с помощью allocateIds(), никогда не должны истекатьНачиная с Назначение идентификаторов :

Автоматический генератор идентификаторов в режиме хранилища данных будет отслеживать идентификаторы, которые были назначены этими методами, и избегать их повторного использования для другой сущности, поэтому вы можете безопасно использоватьтакие идентификаторы без конфликтов.Вы не можете вручную выбирать, какие значения будут возвращены методом allocateIds().Значения, возвращаемые allocateIds(), назначаются в режиме хранилища данных.

Личные соображения, подтверждающие это мнение:

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