Типа без джярников всяких из интернета?

А как это, голая джава?

джарники из интернета все равно были, например драйвер в базе или http клиент. Я скорее говорил по DI / MVC и прочих довольно спорных практиках

Наверное очень интересно эти штуки все с нуля пилить.

джарники из интернета все равно были, например драйвер в базе или http клиент. Я скорее говорил по DI / MVC и прочих довольно спорных практиках

Главное, чтобы они в попытках на использовать di не пришли к тому, что написали свой di

Я не сильно лазил в их кишках, но практически все что я видел, в том проекте, инициализировал явно через конструктор.

Главное, чтобы они в попытках на использовать di не пришли к тому, что написали свой di

это всегда прекрасно. возникает только один вопрос - зачем?

У любого беспредела есть чётко обозначенные границы (с)

это всегда прекрасно. возникает только один вопрос - зачем?

Зачем нужен DI?

нет, зачем нужно заморачиваться не использовать DI и писать свои велосипеды

Зачем нужен DI?

чтобы решить проблему, которой до его изобретения не существовало

Я на собесах так про все паттерны отвечаю

молодец

мы вам не перезвоним

Спасибо!

чтобы решить проблему, которой до его изобретения не существовало

не совсем так, но даже спорить впадлу

@dmsol подозрительные цифры бродят. и тут и в котлин и вообще.

Есть вроде жеж и регистровые реализации, не?

Ну сам-то байт-код для стековой ВМ. Что с ним ВМ будет делать, дело десятое. А на Android сделали так, что при сборке он конвертится в свой формат (регистровый + подобие pack200) и уже в таком виде отправляется на устройство.

Шаблонные строки с какой версии жавы?

Шаблонные строки с какой версии жавы?

Ни с какой, к сожалению

Ага

Я либо с котлином либо с жс попутал

И кстати, вопрос: что делать с потерей соединения во время транзакции? Как можно обработать ситуацию, когда соединение потерялось во время роллбека?

Комрады, вопрос скорее всего уже возникал и не один раз. Как вы организуете структуру проекта. От чего отталкиваетесь, от бизнес-логики или от слоев в организации пакетов? (DDD и все дела). Как мне кажется бессмыслено просто следовать в именовании пакетов слоистости системы. Я обычно организую по подсистемам (бизнес-подсистемам), а далее уже делю на слои в подпакетах (DAL, view, models etc)

И кстати, вопрос: что делать с потерей соединения во время транзакции? Как можно обработать ситуацию, когда соединение потерялось во время роллбека?

Тайм-аут на транзакции ставить.

Тайм-аут на транзакции ставить.

О, внезапно — годная мысль. Спасибо!

Никто не сталкивался с такой проблемой ConcurrentModificationException при entityManager.merge на 5-ом хибернейте?

давно такого не было

помнится такое гуглилось не сильно сложно

Я сейчас загулил и последнеее что увидел это https://stackoverflow.com/questions/11534424/hibernate-throwing-a-concurrentmodificationexception

Поговаривают что это баг, но вчера все отрабатаывало на ура

обычно такие штуки возникают при использовании неперсистентных коллекций и обратных маппингах

ну или совсем что то делаете не так

например порядок сохранения не тот, каскада нет

вариантов много

Проблема в том, что я сейчас смотрю тест и сущность не менял от слова совсем. Но как говорится магии не бывает, так что придется ссмотреть что почем

зависимости же апгрейдите?

без кода что либо сказать будет сложно

ERROR: S client not available

А кода как такового и нет @Transactional public T merge(T entity) { T merged = entityManager.merge(entity); entityManager.flush(); entity.setId(merged.getId()); return entity; }

Падает на .flush

А кода как такового и нет @Transactional public T merge(T entity) { T merged = entityManager.merge(entity); entityManager.flush(); entity.setId(merged.getId()); return entity; }

А почему просто merged не возвращать? Зачем менять исходную сущность руками? Может в этом и проблема?

Исходная сущность же под управлением хибера и при изменении возможно пытается что-то поменять и возникает конфликт с merged

А кода как такового и нет @Transactional public T merge(T entity) { T merged = entityManager.merge(entity); entityManager.flush(); entity.setId(merged.getId()); return entity; }

настараживает @Transactional, сразу наводит на мысли что делается что то не то

Почему настораживает?

он либо а - бесполезен, если транзакция уже есть и entity управляемая, б - если entity не управляемая и транзакции не было, то операция мерджа будет крайне непредсказуема если же управляемая, то вообще бордак

управляемые сущности не должны уходить за пределы транзакции

flush используется для всех инструкций находящихся в кэше. а правда зачем нужно создавать merged? разве копия будет иметь другой указать?

А кода как такового и нет @Transactional public T merge(T entity) { T merged = entityManager.merge(entity); entityManager.flush(); entity.setId(merged.getId()); return entity; }

А почему тут merged не возвращается, а энтити?

3 строчки и столько вопросов) когда решил поиграть с орм и проиграл

когда-нибудь люди откроют для себя JOOQ, и будет счастье

А если оракл?

И всё, платить не хочется

А почему тут merged не возвращается, а энтити?

Это все равно не Проблема в текущем контексте

А если оракл?

https://postgrespro.ru/media/2016/07/20/ignatov_ibm_migration.pdf https://habr.com/company/yamoney/blog/326998/

Вот это шутка

И всё, платить не хочется

А за оракл не платят разве?