и в силу специфики большое количество запросов связаны с JOIN и обнаружил странный момент после длительной работы с typescript (typeorm, knex): в плане работы с базой и маппингов в объекты всё слишком печально, неочевидно и перегружено.
1. До жути простой кейс : есть таблица customers и payments. У customers есть one-to-many связь к payments по полю payments.customer_id. Описан native query запрос к базе с join (без fetch join, чтобы добавить дополнительную аггрегацию суммы всех платежей). В SqlResultSetMapping маппинг описан и в конструкторах всё вызывается, однако, вместо 1 записи возвращается несколько и запрос падает в ошибку .
Если делать fetch join через обычный query (не native), то запрос проходит, однако делать вычисляемые поля отдельными функциями после получения результата из базы- убогий подход, так как это можно сделать при запросе в базу. Это лишь один банальный случай, который появился при начале работы со спрингом, jpa и hibernate'ом.
2. Маппинг данных из jsonb в dto класс.
Тоже максимально странное поведение, что под каждый мелкий класс в случае нативных запросов нужно писать маппер. Есть ли обходное универсальное решение ?
Назначение маппинга понятно, но в силу огромного количества магии как это фиксить, а тем более продолжить разработку массивной системы не понятно и сомнительно из-за крайне большого количества подобных моментов.
ЧЯДНТ ?
А зачем вам вообще резалтсетмаппинг и натив квери?
Без этого маппинг падал с no converter found capable of converting from type на каждом стоблце, в том числе для @ColumnResult(name = "pricing", type = CustomerPricingType.class) так как там структурированные jsonb данные
Если хочешь автомаппинг, то делай @entity под каждый native запрос. @table тогда не нужен.
точно что-то делаешь не так) 1. Есть @Formula например, не подошло? 2. Слишком абстрактно и не ясно как все устроено и в чем проблема
Перетестил все возможные варианты, описанные с начала 10ых годов, до тех, что встречались уже в 20ых годах
Обсуждают сегодня