Size: a a a

2020 July 27

V

Vladimir in pro.jvm
Vladimir
вдруг кто-то еще не пишет на котлине))
и я
источник

AK

Alexander Komarov in pro.jvm
Vladimir
товарищи, подскажите чат по scala
@scala_ru внезапно
источник

A

Aleksandr in pro.jvm
Как часто вы замечали в коде круда ту самую хитрую особенность, которая связана с обновлением существующей энтити через 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

Gennady Lebedev in pro.jvm
а хитрость-то в чем?
он в транзакции вроде сам перед закрытием все сделает
источник

GL

Gennady Lebedev in pro.jvm
Vladimir
товарищи, подскажите чат по scala
источник

A

Aleksandr in pro.jvm
Gennady Lebedev
а хитрость-то в чем?
он в транзакции вроде сам перед закрытием все сделает
Вот как раз в том, что не обязательно повторно делать save
источник

GL

Gennady Lebedev in pro.jvm
ну это, мягко выражаясь, не хитрость
а протечка абстракций и неявное использование

но не слушайте меня, покусан ФП
источник

A

Aleksandr in pro.jvm
Короче, я к тому, что раньше давно напарывался на эту ошибку и потому поделился)
источник

GL

Gennady Lebedev in pro.jvm
AOP вообще одна сплошная дыра и протечка абстракций, но сразу после этого следует вывод что и ООП это ересь)
источник

SP

Sergey Potekhin in pro.jvm
Я считаю, что JPA используют не ради оптимизации, а ради наглядности и читабельности, поэтому я бы не стал выкидывать save. Мало ли, кто-то уберет @Transactional или hibernate изменит поведение. Например в будущей версии появится свойство jpa.hibernate.hiddenops = false  или типа того
источник

D

Dima in pro.jvm
Aleksandr
Вот как раз в том, что не обязательно повторно делать save
на всякий случай всегда так делал, хотя бы ради безопасности и каскадов
источник

SP

Sergey Potekhin in pro.jvm
Если хочется соптимизировать такты процессора, то надо использовать JDBC
источник

ch

central hardware in pro.jvm
Sergey Potekhin
Если хочется соптимизировать такты процессора, то надо использовать JDBC
если мы переходим на оптимизацию тактов то надо вообще на Java не писать
источник

SP

Sergey Potekhin in pro.jvm
ну и это верно тоже
источник

A

Aleksandr in pro.jvm
central hardware
если мы переходим на оптимизацию тактов то надо вообще на Java не писать
Почему же?
источник

D

Dima in pro.jvm
что касается оптимизаций, даже в самом JPA многие пренебрегают @EntityGraph
источник

D

Dima in pro.jvm
native query etc
источник

GL

Gennady Lebedev in pro.jvm
central hardware
если мы переходим на оптимизацию тактов то надо вообще на Java не писать
кстати, нет
jvm прогретый код выполняет, в целом, эффективно

все проблемы - от IO

за 7+ лет разработки кровавого был 1, ровно 1 раз когда тормозил именно код, а не сеть/диск/кривые локи
источник

h

humanoid in pro.jvm
все зависит от кейса
источник

h

humanoid in pro.jvm
у кого то упрется в код
источник