на сущность. вроде всё понятно, алгоритм тот же что и для обычной таблицы. но проблема в том, что у строк в представлении нет первичного ключа, составной сделать то же не подойдет, а хиберу обязательно нужен какой то идентификатор. я пока временно сделал так - в исходном коде представления генерирую UUID таким образом: uuid_in(md5(random()::text || random()::text)::cstring) as id
нет ли других способов?
В сущностях обязательно должен быть ID, это в спеке JPA прописано. Так что надо как-то этот ID делать по-любому. Ваш способ, наверное, годный, пока дело не дойдет до сравнения двух объектов из разных сессий. Я правильно понимаю, что выборка одной и той же строки в разных сессиях будет с разными рандомными ID?
не использовать jpa в этом конкретном месте например
да, раньше я и не использовал, но лид сказал "шоб везде одинакова було"
ну да, тут проблем быть не должно
Кроме производительности базы, если у вас там миллионы строк выбираются в разных сессиях и надо будет огромную кучу рандомов генерировать. А что, совсем-совсем нет ID? У вас там view с distinct выбирается что ли?
я тестил и на производительность почти не повлияло, там разница в 10-40 мс
хибер умеет сразу в дто кстати выбирать, ещё есть spring data projections
там запрос(исходник представления) кривоватый , есть вариант его подрефакторить
А, ну ОК. Так-то без понимания всей задачи и ограничений сложно прям точный совет выдать, что делать.
Обсуждают сегодня