Я работаю над настольным приложением в Java6, используя H2 в качестве базы данных и Hibernate 3.6.
Из-за конструкции со сторонней библиотекой, включающей JNI, и некоторых интересных решений, принятых априори, яне может передавать длинные идентификаторы в коде индекса и может передавать только int.Эти индексы генерируются быстро и многократно (не мой выбор) и передаются через обратные вызовы.Тем не менее, я могу разбить ожидаемый набор данных по строкам строкового значения и сохранить размер идентификатора int, не выбрасывая идентификаторы.С этой целью я сохраняю длинное значение pk на базовом объекте, а затем использую его как один-к-одному в другую таблицу, где он отображает int id обратно в базовую сущность, которая в сочетании сstring, является уникальным.
Итак, я рассмотрел встроенные составные ключи и тому подобное в спящем режиме, но я действительно хочу, чтобы просто иметь этот «дополнительный» идентификатор, который уникален в контексте дополнительного строкового ключа,но не обязательно универсально уникальным.
Так что-то вроде (без добавления постороннего кода / аннотаций):
@Entity
public class Foo{
...
@Id
public Long getId(){...}
...
@OneToOne
@PrimaryKeyJoinColumn
public ExtraKey getExtra(){...}
}
@Entity
public class ExtraKey{
...
@Id
public Long getFooId(){...}
...
public Integer getExtraId(){...}
...
public String getMagicString(){...}
}
В таком случае, я мог бы даже удалить magicString и просто получить fooId-> отображение extraId в таблице, а затем добавление extraId + magicString в другое, где magicString уникально.Однако я хочу, чтобы hibernate позволял создавать новые magicString по своему усмотрению (требование приложения), в идеале по одному на строку в таблице, а затем иметь hibernate, просто обновляя extraId, связанный с этим magicString, с помощью стратегии приращения / других.
Просматривая все руководства по спящему режиму и пытаясь самостоятельно провести несколько тестов в отдельной среде, я не получил желаемого (в основном, динамически создаваемые именованные и последовательные идентификаторы), поэтому я надеялся на ввод SO.Вполне возможно, мне придется самому кодировать все это вручную в БД с последовательностями или разделением long и логикой по верхнему и нижнему, но я бы на самом деле не хотел, так как мне, возможно, придется когда-нибудь поддерживать этот код(очень вероятно).
Редактировать / Дополнение
В качестве хитрого способа обойти это, я просто добавляю extraId к объекту Foo (исключая extraKeyclass) и генерирует его из другого объекта-одиночки, который во время загрузки делает группу с помощью выбора по вспомогательной таблице Foo, возвращая magicKey и max (extraId).Когда я создаю новый Foo, я прошу этот объект (многопоточный сейф) передать мне следующий extraId для данного magicKey и вставить его в Foo, и сохранить его, таким образом, обновляя мой эффективный extraId для каждого magicKey при следующей перезагрузке приложения без дополнительнойТаблица.Это стоит мне одну группу по запросу при первом запросе нового extraId, который является неоптимальным, но достаточно быстрым для того, что мне нужно, достаточно простым для поддержки в будущем, и все содержится во внешнем классе, поэтому я МОГУ заменить егов одном месте, если я когда-нибудь придумаю что-нибудь более умное.Мне не нравится иметь дополнительный «специальный запрос» в моем дао для этой цели, но его достаточно легко удалить в будущем, и он хорошо документирован.