ЕМНИП, такое делать на нагруженной таблице нельзя, т.к. на таблицу устанавливается эксклюзивная блокировка. И правильнее сначала отсоединять партицию, а потом уже дропать.
Пример? Из двух проектов, где я это выпиливал, это было говнорешением. И видя проблемы, которые оно приносило, я не вижу ни одной причины, где его использование было бы хоть как-то оправдано.
аудит на JPA
Как я и сказал ранее, не нужно, если только, конечно, это не тупой crud, без какой-либо логики. Таких проектов я ни разу не видел в реальной разработке.
Некоторые утверждают что Spring - opinionated
И они, в принципе, правы на все 146%. java-бэкэнд ≠ spring-приложение. Можно прекрасно обходиться и без него.
вырастает целый самодельный фреймворк … без возможности осознанного выбора и изменения в будущем.
Как бы перпендикулярные утверждения, нет? С чего это я не смогу внести изменения в свой код? И выбор писать своё, как раз таки более осознан, нежели тащить себе третьестороннюю зависимость с её багами, ограничениями и т.п.
сниппет на три поля
Вообще-то, я имел ввиду, 3 сниппета, т.к. не везде нужно версионирование и дата создания одновременно. Где-то достаточно чего-то одного, а где-то и ничего из этого.
один generic-контроллер по сущностям это уже как раз немного выглядик как антипаттерн
Антипаттерн - это плодить кучу одинаковых объектов (бинов) в памяти, без которых можно обойтись.
Ты увидишь BaseEntity с id, createdDate и version. Увидишь AbstractCrudController<T, ID>, от которого наследуются все твои контроллеры. Увидишь самодельный слой прав — что-нибудь вроде @CheckPermission поверх PermissionEvaluator. Увидишь свой SoftDeleteRepository и аудит-слушатель на JPA-события.
Вообще ни разу не попал.
Наследование сущностей - самое тупое, что можно придумать. Даже если на старте это кажется хорошей идеей, то потом с этим будут проблемы. Нет никакой проблемы скопипастить 3 поля (продвинутые пользователи используют для этого сниппеты кода в IDE).
Контроллер - контракт взаимодействия с внешним миром. Если он для всех сущностей одинаковый, то нахрен не нужны 100500 контроллеров, сделай 1 и раздели маршрутизацию по сущностям.
Мы ж спринговое приложение рассматриваем, поэтому возьмём спринговый сесурити и не будем костылять.
Аудит-слушатель на JPA-события (именно как аудит, целью прописать кто/что сделал) не нужен примерно никогда. Аудит нужен на вызовы бизнес-операций, возможно, на всякие вызовы внешних сервисов с запросом данных, но только на JPA-события - эталонное НЕНУЖНО.
Если у тебя есть боевой Spring-проект старше двух лет без самопального BaseEntity, generic-CRUD и самодельного слоя прав внутри — брось ссылку в комментарии.
Я бы кинул, но ИБ будет против. Но ваш аргумент, конечно, уровня “сперва добейся”.
Тут, думается, зависит от жадности адвоката. Условно, если сотруднику надо будет выплатить X, а адвокат согласен на X/2, то, конечно, дешевле.
И чем больше X, тем меньше вероятность принципиальности адвоката. Плюсом он же ещё и с клиента денежку возьмёт. С его точки зрения ситуация win-win.
Главная проблема всей юриспруденции (и всяких медицин, культур, литератур) - субъективность. Зачастую, “по закону” и “по справедливости” - это могут быть как противоположные так и одинаковые понятия. Человек, идя в суд, всегда ожидает второе, но получает всегда первое. Плюс нет строгого алгоритма трактования законов (если X, то Y), судья следует своим принципам, убеждениям и пониманием закона.
Какой-то тупень, не читавший сказку, типа, сумничал. Коза не ходила за молоком, она ходила в лес пожрать, а уже приходя домой, наевшись, говорила, что принесла молока.
Вообще нет. Это проблема всех, т.к. до понимания того, что форма - GodObject и это есть плохо надо ещё дорасти. А как дорасти, если в каждом первом учебнике об этом рассказывалось чуть реже, чем никогда. Все примеры - это именно когда в обработчиках накидана вся бизнес-логика. На чём учиться хорошему?
Меня вот что интересует: для всяких коллекций/массивов/etc. заменить null на какой-нибудь дефолтовый пустой контейнер не проблема даже сейчас, то как быть, если у меня свой value class, кто будет определять что есть дефолтовое значение?
Если просто нельзя будет в переменную положить null, то как это предполагается реализовывать, на каком уровне: компилятора или самого байткода?
95% покрытие веток интеграционными тестами … Jackson 3 начал при десереализации отдавать предпочтение дефолтным значениям… Jackson 3 начал в этом случае бросать исключение
Т.е. основной функционал десериализации таки попал в эти 5%? Действительно, зачем валидировать входящие данные, кому нужны тесты на гетеры. :)
Особенно прекрасно в этом вопросе, предполагаемый ответ джуна “нет, будет меньше”. А почему, собственно, не рассматривается вариант “мне повезёт”, и будет именно столько, сколько ожидается?
Ведь именно этот вариант и является причиной багов на проде. А если сразу получаем неправильное значение, то даже юнит-тесты это отловят.
ЕМНИП, такое делать на нагруженной таблице нельзя, т.к. на таблицу устанавливается эксклюзивная блокировка. И правильнее сначала отсоединять партицию, а потом уже дропать.
Ошибка перевода или автор реально хотел с 10 до 20 лет получить вышку?
Пример? Из двух проектов, где я это выпиливал, это было говнорешением. И видя проблемы, которые оно приносило, я не вижу ни одной причины, где его использование было бы хоть как-то оправдано.
Как я и сказал ранее, не нужно, если только, конечно, это не тупой crud, без какой-либо логики. Таких проектов я ни разу не видел в реальной разработке.
И они, в принципе, правы на все 146%. java-бэкэнд ≠ spring-приложение. Можно прекрасно обходиться и без него.
Как бы перпендикулярные утверждения, нет? С чего это я не смогу внести изменения в свой код? И выбор писать своё, как раз таки более осознан, нежели тащить себе третьестороннюю зависимость с её багами, ограничениями и т.п.
Вообще-то, я имел ввиду, 3 сниппета, т.к. не везде нужно версионирование и дата создания одновременно. Где-то достаточно чего-то одного, а где-то и ничего из этого.
Антипаттерн - это плодить кучу одинаковых объектов (бинов) в памяти, без которых можно обойтись.
Вообще ни разу не попал.
Наследование сущностей - самое тупое, что можно придумать. Даже если на старте это кажется хорошей идеей, то потом с этим будут проблемы. Нет никакой проблемы скопипастить 3 поля (продвинутые пользователи используют для этого сниппеты кода в IDE).
Контроллер - контракт взаимодействия с внешним миром. Если он для всех сущностей одинаковый, то нахрен не нужны 100500 контроллеров, сделай 1 и раздели маршрутизацию по сущностям.
Мы ж спринговое приложение рассматриваем, поэтому возьмём спринговый сесурити и не будем костылять.
Софт делит - зло.
Аудит-слушатель на JPA-события (именно как аудит, целью прописать кто/что сделал) не нужен примерно никогда. Аудит нужен на вызовы бизнес-операций, возможно, на всякие вызовы внешних сервисов с запросом данных, но только на JPA-события - эталонное НЕНУЖНО.
Я бы кинул, но ИБ будет против. Но ваш аргумент, конечно, уровня “сперва добейся”.
Таки да, этого колобка зачастую не хватает :).
На картинке их 9. Чё по бабочке? Зачем её перекрасили?
Вот когда станет доступна всем, тогда и приходите с обзорами.
Тут, думается, зависит от жадности адвоката. Условно, если сотруднику надо будет выплатить X, а адвокат согласен на X/2, то, конечно, дешевле.
И чем больше X, тем меньше вероятность принципиальности адвоката. Плюсом он же ещё и с клиента денежку возьмёт. С его точки зрения ситуация win-win.
Главная проблема всей юриспруденции (и всяких медицин, культур, литератур) - субъективность. Зачастую, “по закону” и “по справедливости” - это могут быть как противоположные так и одинаковые понятия. Человек, идя в суд, всегда ожидает второе, но получает всегда первое. Плюс нет строгого алгоритма трактования законов (если X, то Y), судья следует своим принципам, убеждениям и пониманием закона.
И с этим by design ничего не сделать.
Какой-то тупень, не читавший сказку, типа, сумничал. Коза не ходила за молоком, она ходила в лес пожрать, а уже приходя домой, наевшись, говорила, что принесла молока.
Не просто программистом, а джуном.
Не
уволилисоптимизировали - уже хорошо.Вообще нет. Это проблема всех, т.к. до понимания того, что форма - GodObject и это есть плохо надо ещё дорасти. А как дорасти, если в каждом первом учебнике об этом рассказывалось чуть реже, чем никогда. Все примеры - это именно когда в обработчиках накидана вся бизнес-логика. На чём учиться хорошему?
уж не Василий ли? Элитный вайбкодер за $200/ч.
Это принесло много лулзов и практических примеров того, как делать не стоит.
Меня вот что интересует: для всяких коллекций/массивов/etc. заменить
nullна какой-нибудь дефолтовый пустой контейнер не проблема даже сейчас, то как быть, если у меня свойvalue class, кто будет определять что есть дефолтовое значение?Если просто нельзя будет в переменную положить
null, то как это предполагается реализовывать, на каком уровне: компилятора или самого байткода?Так победимЪ. (ц) HUAWEI
Т.е. основной функционал десериализации таки попал в эти 5%? Действительно, зачем валидировать входящие данные, кому нужны тесты на гетеры. :)
Эм-м-м, потому что могу?
Или даже так
А зачем заблюрил результаты?
Особенно прекрасно в этом вопросе, предполагаемый ответ джуна “нет, будет меньше”. А почему, собственно, не рассматривается вариант “мне повезёт”, и будет именно столько, сколько ожидается?
Ведь именно этот вариант и является причиной багов на проде. А если сразу получаем неправильное значение, то даже юнит-тесты это отловят.