Есть модель водителя:


При обновлении информации о водителе, присылается полностью вся модель с заполненными данными. Далее происходит обновление:


Мне не нравится, что при обновлении, например, просто имени, приходится таскать всю эту длинную модель с заполненными данными. Если, например, номер телефона не меняется, в private String phone; приходит нулл, но при save(driver) в базе обнуляется старый телефон, а этого быть не должно. Как бы это красиво разрулить? Спасибо.

BlazkowiczJulTМне не нравится
Интнересный критерий. А заказчик знает?
Откуда приходят данные, что вас напрягает их количество?
Почемы данные не находятся в кэше?
Что именно даст такая оптимизация помимо вашего морального удовлетворения?



Данные приходят с ios-клиента. Если какие-то поля в моделе не заполнены, при сохранении они обнуляются, а мне их (поля) не шлют не потому что их нужно обнулить, а чтобы не гнать с клиента длинную простыню с данными

BlazkowiczJulTДанные приходят с ios-клиента. Если какие-то поля в моделе не заполнены, при сохранении они обнуляются, а мне их (поля) не шлют не потому что их нужно обнулить, а чтобы не гнать с клиента длинную простыню с данными
Как делается в нормальных ORM. Читам драйвера по id из репозитория. Так как iOS клиент недавно загружал этого драйвера, то запись должна быть в кэшах и чтение стоит минимум. Записываем в объект свойства, которые приехали из клиента.
В Hibernate остаётся только закомитить транзакцию, чтобы он обнаружил обновленные свойства и проапдейтил запись в базе.
Что конкретно смущает? Наличие кэша?
наличие кеша

smackmychiNixic,

Увы, я не гадалка и оснований для очевидности кроме фактов из уст автора взять не могу.
DriverRepository driverRepository

Nixicа чего вас смущает не пойму, написали один раз метод апдейта, типа:

Приведу пример из моего проекта, где апдейтится все через персистенс EntityManager и т.д.

Генерируем геттеры и сеттеры для нашего класса Driver, потом используем их




Все это конечно через трай и т.д.

В итоге берем нашего шофера
меняем ему имя:





Точно так же можно написать методы и для JDBC или другого.
у меня Spring Data

BlazkowiczJulTналичие кеша
ORM без кэша это кайф.
Ок, прописать в конфигах для хибера пару строчек для использования кеша - это не проблема. А как мне вытащить объект из кеша, учитывая то, что я использую спринг дата. Обычно я делаю так: driverRepository.findOne(driverId) - если в конфигурации прописано использование кеша второго уровня, гарантирует ли это, что при вызове findOne объект будет подтянут именно из кеша? Простите если задаю глупые вопросы, просто не совсем могу уловить смысл. Спасибо

BlazkowiczJulTОк, прописать в конфигах для хибера пару строчек для использования кеша - это не проблема. А как мне вытащить объект из кеша, учитывая то, что я использую спринг дата. Обычно я делаю так: driverRepository.findOne(driverId) - если в конфигурации прописано использование кеша второго уровня, гарантирует ли это, что при вызове findOne объект будет подтянут именно из кеша? Простите если задаю глупые вопросы, просто не совсем могу уловить смысл. Спасибо
Чтобы изменить поля у сущности, пользователь эту сущность должен сначала увидеть.
Чтобы показать пользователю сущность, её состояние надо вычитать из БД.
При чтении сущность попадает в кэш.
Поэтому с вероятностью 99%, при вызове операции изменения свойств, сущность будет жить в кэше. Поэтому чтение её по id стоит ничтожно мало.
в таком случае мне достаточно прописать в конфигурации:

Если я включаю кеш второго уровня, нужно ли при этом добавлять для сущности следующее:
@Entity
@Table(name = "driver")
@Cache(usage = CacheConcurrencyStrategy.READ_WRITE)
?