Если нам нужна коллекция уникальных элементов, заменив HashSet на ArrayList мы переложим ответственность за поддержание уникальности на себя. Придётся каждый раз вызывать contains и все в этом духе, то есть писать лишний код. А в сете это все уже за нас написано, пусть по производительности он будет сведён к массиву в случае константного hashCode. Да и что делать с Map?
Проблема в том, что иногда hashCode просто не от чего считать, вот и приходится выбирать между плохим решением и решением ещё хуже. Сущность, где все поля мутабельны — как раз такой случай
Да, это вопрос на отдельную статью :) Вот хорошая: thorben-janssen.com/ultimate-guide-to-implementing-equals-and-hashcode-with-hibernate
TL;DR:
1. Если объекты будут всегда сравниваться в пределах одной сессии Хибернейта, можно equals и hashCode вообще не переопределять
2. Если есть natural id или id выставляется самим приложением, используем только его в equals и hashCode
3. Если id генерирует база, используем его в equals и возвращаем из hashCode некоторую константу. Да, это ухудшит производительность коллекций на хешах, но серьезно это начнет влиять с такого количества объектов, что узким местом скорее станет сам факт вытаскивания их из БД. Такова идея, конечно, в реальном мире все зависит от того, как часто к этим коллекциям обращаться
К вопросу об инструментах (да, вопрос очень старый, но статья до сих пор отлично гуглится :)
В идее можно генерировать дифференциальные Flyway скрипты, сравнивая модель и БД, одну БД и другую БД, а также модель со снапшотом этой же модели другой версии (из мастера, например)
То есть флоу такой: внес изменения в JPA-модель -> сгенерил скрипты с разницей -> смигрировал базу. И так до бесконечности :)
Делает это плагин под названием JPA Buddy, выглядит вот так:
Пока нет, но в основном это касается только генерации Liquibase-скриптов, которые для H2 вроде не особо нужны, для прототипов auto-ddl обычно достаточно. Или еще какой-то юзкейс есть?
Если нам нужна коллекция уникальных элементов, заменив HashSet на ArrayList мы переложим ответственность за поддержание уникальности на себя. Придётся каждый раз вызывать contains и все в этом духе, то есть писать лишний код. А в сете это все уже за нас написано, пусть по производительности он будет сведён к массиву в случае константного hashCode. Да и что делать с Map?
Проблема в том, что иногда hashCode просто не от чего считать, вот и приходится выбирать между плохим решением и решением ещё хуже. Сущность, где все поля мутабельны — как раз такой случай
TL;DR:
1. Если объекты будут всегда сравниваться в пределах одной сессии Хибернейта, можно equals и hashCode вообще не переопределять
2. Если есть natural id или id выставляется самим приложением, используем только его в equals и hashCode
3. Если id генерирует база, используем его в equals и возвращаем из hashCode некоторую константу. Да, это ухудшит производительность коллекций на хешах, но серьезно это начнет влиять с такого количества объектов, что узким местом скорее станет сам факт вытаскивания их из БД. Такова идея, конечно, в реальном мире все зависит от того, как часто к этим коллекциям обращаться
В идее можно генерировать дифференциальные Flyway скрипты, сравнивая модель и БД, одну БД и другую БД, а также модель со снапшотом этой же модели другой версии (из мастера, например)
То есть флоу такой: внес изменения в JPA-модель -> сгенерил скрипты с разницей -> смигрировал базу. И так до бесконечности :)
Делает это плагин под названием JPA Buddy, выглядит вот так: