В прследнее время я пользуюсь to_jsonb и jsob_build_object с последующей сериализации через jackson.
Это устраняет вопрос маппинга как таковой, мы получаем привычный нам jsonчик включающий все нужные поля, в т.ч. массивы с нужными условиями выборки, без танцев с бубном
в общем вы и описываете почему таких вопросов надо сторонится. Живите в своем вымышленном мире, где родословная стандартных классов - очень полезная информация
ок, сегодня он в в utils, завтра Oracle петух клюнет и он переедет, как было с тем, что пошло в пакет Jakarta. В чем польза этого знания, хоть минимальная? Я то может и помню, как и автор ответил на вопрос. Но если работодатель считает эти знания ценными - это уже звоночек, что что-то у него не так
о чем вы? О PostgreSQL условно?) Так иначе не выйдет
2жды пробрасывать ошибку? Или разные?
зачем?
а зачем, если нам нужен уникальный индекс по email в бд и обработка ошибки?
Зачем всё усложнять?
ого, что де может значить when not matched если when matched означает что делать, если условие выполняется
Загадка
ну да. Ведь если проблемы на проде то ответа "а на тесте все хорошо" всегда достаточно. Ну проблемы и проблемы, не решать же их
а чем по вашему пользуются на западе?)
MySQL? Oracle? MS SQL может?!
PostgreSQL - прекрасный продукт
да не, вполне читаемая конструкция будет.
Только с or могут индексы ломаться, я обычно делаю
case when :id is null then true else :id=id end
Ну и так хоть сотню, нет больших проблем.
Оптимизатор запроса видит условия еще перед выполнением и просто выкидывает не нужные ветки (в отличие от or)
Что-то мне подсказывает, что если выкинуть jpa и использовать нативный sql - никакие кэши не понадобятся.
В статье не видно структуру таблиц и количество данных, но я почему-то уверен)
Ну и проверить что за запросы генерирует orm было бы не плохо. Может там циклическая зависимость entity a ссылается на с, которая ссылается на а ...
этот подход крут пока мв не утыкаемся в сенсетив дату, которую в лог нельзя
Ну SQL это не ЯП)
Как минимум симейство. (как максимум вообше не ЯП, т.к. он хоть и тьюринг-полны, но во первых не сразу, в вторых ну камон, это не ЯП)
Т.е. тогда Lisp надо вспоминать с вполне современным Clojure
ну ты случайно намусорил коммитами и хочешь их засквашить.
А кто-то паралельно в твою ветку пушнул что-то. Ты не хотел ему мешать, ты свое хотел почистить
за 20 лет умирают концепции и подходы
уже стандарт де-факто, заплюют же. Благо котлин писали умные люди
я бы сказал, что иногда документация такая, что не удаётся понять про что проект, не говоря про то как с ним работать
вы еще скажите физическую книгу про физику, зачем новичку руками с памятью работать, ну
В прследнее время я пользуюсь to_jsonb и jsob_build_object с последующей сериализации через jackson.
Это устраняет вопрос маппинга как таковой, мы получаем привычный нам jsonчик включающий все нужные поля, в т.ч. массивы с нужными условиями выборки, без танцев с бубном
Не доказано, что с помощью полиграфа можно понять лжет ли человек. Он просто показывает "что-то". Состояние человека.
в общем вы и описываете почему таких вопросов надо сторонится. Живите в своем вымышленном мире, где родословная стандартных классов - очень полезная информация
ок, сегодня он в в utils, завтра Oracle петух клюнет и он переедет, как было с тем, что пошло в пакет Jakarta. В чем польза этого знания, хоть минимальная? Я то может и помню, как и автор ответил на вопрос. Но если работодатель считает эти знания ценными - это уже звоночек, что что-то у него не так
главное, что полиграф - псевдонаучное устройство. И как можно работать с людьми верящими в псевдонауку - вопрос