Масштабируемый генератор последовательных идентификаторов для связанных объектов с использованием @TableGenerator - PullRequest
0 голосов
/ 12 марта 2011

Я пишу веб-приложение, в котором некоторые идентификаторы будут видны пользователям в URL. Приложение предназначено для использования большим количеством пользователей, имеющих каждую учетную запись. У учетной записи могут быть проекты, а у каждого проекта есть задачи.

Теперь я не хочу, чтобы пользователи создавали свой первый проект с идентификатором 24876 (или каким-либо другим сгенерированным идентификатором), а скорее имел бы «красивый» последовательный идентификатор дополнительно к сгенерированному первичному ключу (главным образом потому, что проще манипулировать объектами, имеющими несоставные идентификаторы). Давайте назовем эти последовательные идентификаторы viewIds.

ViewID будут начинаться с 1 для каждого отдельного «родительского» идентификатора (для Проекта это будет Учетная запись). Комбинация (accountId, projectViewId) является уникальной, а также (projectId, taskViewId) и т. Д.

Мой вопрос: как генерировать эти viewIds? Я думал о том, чтобы, возможно, использовать механизм TableGenerator , но может ли он также использоваться для столбцов без идентификатора?

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

1 Ответ

0 голосов
/ 26 мая 2011

Хорошо, это решение, которое я в итоге принял:

вместо того, чтобы полагаться на Hibernate / JPA для управления этими "красивыми" идентификаторами, я выбрал подход на основе базы данных:

  • Для каждого объекта с viewID, я определяю триггер, который будет увеличивать его при каждой вставке, основываясь на максимуме элементов в одной последовательности (например, все задачи для проекта 22)
  • У меня также естьограничение нескольких уникальных ключей для (project_id, naturalId) для таких объектов, как Task.

Одна вещь, в которой я не уверен, это то, как это будет вести себя, например, при репликации master-to-masterбаза данных, где могут использоваться оба сервера базы данных.Но для репликации сервера приложений это должно сработать.

...