V
Size: a a a
2020 July 27
AK
A
Как часто вы замечали в коде круда ту самую хитрую особенность, которая связана с обновлением существующей энтити через
Попалась статейка и сам заметил это https://habr.com/ru/post/441386/
Говорю конкретно про метод save у SimpleJpaRepository:
save метод JPA?@Transactional
public BankAccount updateRate(Long id, BigDecimal rate) {
BankAccount account = repo.findById(id).orElseThrow(NPE::new);
account.setRate(rate);
return account; // return repo.save(account)
}
Попалась статейка и сам заметил это https://habr.com/ru/post/441386/
Говорю конкретно про метод save у SimpleJpaRepository:
@Transactional
@Override
public <S extends T> S save(S entity) {
if (entityInformation.isNew(entity)) {
em.persist(entity);
return entity;
} else {
return em.merge(entity);
}
}
GL
а хитрость-то в чем?
он в транзакции вроде сам перед закрытием все сделает
он в транзакции вроде сам перед закрытием все сделает
GL
товарищи, подскажите чат по scala
A
а хитрость-то в чем?
он в транзакции вроде сам перед закрытием все сделает
он в транзакции вроде сам перед закрытием все сделает
Вот как раз в том, что не обязательно повторно делать save
GL
ну это, мягко выражаясь, не хитрость
а протечка абстракций и неявное использование
но не слушайте меня, покусан ФП
а протечка абстракций и неявное использование
но не слушайте меня, покусан ФП
GL
AOP вообще одна сплошная дыра и протечка абстракций, но сразу после этого следует вывод что и ООП это ересь)
SP
Я считаю, что JPA используют не ради оптимизации, а ради наглядности и читабельности, поэтому я бы не стал выкидывать save. Мало ли, кто-то уберет @Transactional или hibernate изменит поведение. Например в будущей версии появится свойство jpa.hibernate.hiddenops = false или типа того
SP
Если хочется соптимизировать такты процессора, то надо использовать JDBC
ch
Если хочется соптимизировать такты процессора, то надо использовать JDBC
если мы переходим на оптимизацию тактов то надо вообще на Java не писать
SP
ну и это верно тоже
A
если мы переходим на оптимизацию тактов то надо вообще на Java не писать
Почему же?
D
что касается оптимизаций, даже в самом JPA многие пренебрегают @EntityGraph
GL
если мы переходим на оптимизацию тактов то надо вообще на Java не писать
кстати, нет
jvm прогретый код выполняет, в целом, эффективно
все проблемы - от IO
за 7+ лет разработки кровавого был 1, ровно 1 раз когда тормозил именно код, а не сеть/диск/кривые локи
jvm прогретый код выполняет, в целом, эффективно
все проблемы - от IO
за 7+ лет разработки кровавого был 1, ровно 1 раз когда тормозил именно код, а не сеть/диск/кривые локи
h
все зависит от кейса
h
у кого то упрется в код