Да банальная поддержка инфраструктуры, чтобы вся эта баллалайка работала, стоит немалой копеечки. А уж сомнений в том, что поддержкой будут заниматься “кто следоваит” нет никаких абсолютно.
Я уже говорил тебе, что такое безумие, а? Безумие–это точное повторение одного и того же действия. Раз за разом, в надежде на изменение. Это есть безумие.
Наше всё - это умение пользоваться мозгом и логами. Что мавен, что грэдл в стдаут выплёвывают какой тест запущен, собрать последовательность, которая приводит к падению, дело 2-5 минут.
Метод в яве не может быть анонимным, by, мать его, desugn. Функции - не first-class citizens тут. Анонимным может быть класс, коими, очень-очень грубо говоря, являются лямбды.
Проблема с merge() в спрингдатных репозиториях в абсолютно идиотском решении сделать репозиторий по умолчанию транзакционным. Репозиторий - это только доступ к данным, управление транзакциями - это уже инфраструктурный уровень, и заниматься этим должны соответствующие фасады.
Причём можно же было сделать по-нормальному, раз уж так хотелось обмазаться аннотациями, и указать @Transactional(propagation = MANDATORY). При таком подходе merge() из save() можно было бы невозбранно выбросить и ничего не поменялось. Но в угоду красивым презентациям сделали как сделали. В результате получаем выходы сущностей за границы транзакций со всеми вытекающими.
Правильный вариант:
И тут мы плавно подходим к тому, что декларируемая (ничего общего с реальностью не имеющая, конечно) взаимозаменяемость разных spring-data-XXX идёт лесом, т.к. решили мы заменить JPA на jdbc, и вот уже наше обновление сломалось, просто потому, что save-то никто и не сделал.
Если внимательно посмотреть на возвращаемый методом результат и немного подумать, то можно увидеть, что метод возвращает CompletableFuture, следовательно, метод - асинхронный. То, что в каких-то граничных случаях он ведёт себя синхронно, не означает, что с ним можно так работать.
По выходу из этого метода, вообще не факт, что событие отправлено, т.ч. маркировать сущность как отправленную и сохранять её в БД - преждевременно.
outboxRepository.save(record);
Зачем? Чтобы просто погонять лишние запросы в БД? Ты же только что эти записи из БД получил, при комите транзакции JPA сам разберётся, что надо флашить, а что нет.
Так тебе? Или таки твоему работодателю, а ты просто исполняешь работы по замене? Если второе, то бюррократия работает в обе стороны, написал бумажку и жди. Жопа бумажкой прикрыта.
Тратить свои деньги не на себя - заведомо провальная стратегия.
Да это либо жирный тролль, либо сказочный д…б, работающий в одно лицо над одним древнючим проектом, в котором, кроме как, условно, поменять надпись на кнопке, ничего делать не нужно.
На заре моей карьеры даже матёрые фокспрошники, по нескольку раз в день зипающие весь проект в архив, узнав про актуальный тогда svn сразу признали, что это куда лучше, чем мегабайты кода, которые перелопатить при возникновении НЁХ не представляется возможным. Особенно, когда реально надо точечно откатить изменения, а не до конкретной версии.
Или того хуже: цифровым рублём получить. ;)
Твёрдо и чётко.
Знамо дело куды...
Накопление - график функции идёт вверх, сбережение - прямая параллельная абсциссе.
Да банальная поддержка инфраструктуры, чтобы вся эта баллалайка работала, стоит немалой копеечки. А уж сомнений в том, что поддержкой будут заниматься “кто следоваит” нет никаких абсолютно.
Наше всё - это умение пользоваться мозгом и логами. Что мавен, что грэдл в стдаут выплёвывают какой тест запущен, собрать последовательность, которая приводит к падению, дело 2-5 минут.
Да-да, там же не дураки сидят…
Ну, вы чего?
Да нет в яве анонимных методов.
Вообще нет.
Метод в яве не может быть анонимным, by, мать его, desugn. Функции - не first-class citizens тут. Анонимным может быть класс, коими, очень-очень грубо говоря, являются лямбды.
Нет. Stream закрывает соответствующий метод, а не любая терминальная операция.
Только что придуманный автором термин.
И снова вынужден вас огорчить. (ц) Функциональеый интерфейс - это интерфейс с одним нереализованным методом. Методов может быть сколько угодно.
Чтобы не задаваться подобными вопросами, например.
Проблема с
merge()в спрингдатных репозиториях в абсолютно идиотском решении сделать репозиторий по умолчанию транзакционным. Репозиторий - это только доступ к данным, управление транзакциями - это уже инфраструктурный уровень, и заниматься этим должны соответствующие фасады.Причём можно же было сделать по-нормальному, раз уж так хотелось обмазаться аннотациями, и указать
@Transactional(propagation = MANDATORY). При таком подходеmerge()изsave()можно было бы невозбранно выбросить и ничего не поменялось. Но в угоду красивым презентациям сделали как сделали. В результате получаем выходы сущностей за границы транзакций со всеми вытекающими.И тут мы плавно подходим к тому, что декларируемая (ничего общего с реальностью не имеющая, конечно) взаимозаменяемость разных
spring-data-XXXидёт лесом, т.к. решили мы заменить JPA на jdbc, и вот уже наше обновление сломалось, просто потому, что save-то никто и не сделал.потому что сам и ответил.
Если внимательно посмотреть на возвращаемый методом результат и немного подумать, то можно увидеть, что метод возвращает
CompletableFuture, следовательно, метод - асинхронный. То, что в каких-то граничных случаях он ведёт себя синхронно, не означает, что с ним можно так работать.По выходу из этого метода, вообще не факт, что событие отправлено, т.ч. маркировать сущность как отправленную и сохранять её в БД - преждевременно.
Зачем? Чтобы просто погонять лишние запросы в БД? Ты же только что эти записи из БД получил, при комите транзакции JPA сам разберётся, что надо флашить, а что нет.
В svn можно было поставить lock на файл. А самое сложное, когда закончил работать, не забыть снять.
Сразу видно человека, который не знает, что программист не решает аппаратные проблемы.
Такой файлообменник сгубили…
Так тебе? Или таки твоему работодателю, а ты просто исполняешь работы по замене? Если второе, то бюррократия работает в обе стороны, написал бумажку и жди. Жопа бумажкой прикрыта.
Тратить свои деньги не на себя - заведомо провальная стратегия.
Да это либо жирный тролль, либо сказочный д…б, работающий в одно лицо над одним древнючим проектом, в котором, кроме как, условно, поменять надпись на кнопке, ничего делать не нужно.
На заре моей карьеры даже матёрые фокспрошники, по нескольку раз в день зипающие весь проект в архив, узнав про актуальный тогда svn сразу признали, что это куда лучше, чем мегабайты кода, которые перелопатить при возникновении НЁХ не представляется возможным. Особенно, когда реально надо точечно откатить изменения, а не до конкретной версии.