12rbah

Но это стало уже не очень удобным, потому что запросов много, и все их нада выносить в интерфейс.

А точно это нужно? Просто если это интерфейс на 20+ методов, то в этом нет смысла, интерфейс нужен для кода, который может быть обобщенным, просто так выносить метод в интерфейс не имеет смысла.

Сейчас дошло до того, что у меня отдельный интерфейс с базой, прокинут в каждый сервис, и для каждого сервиса с есть метод, вынесенный в интерфейс model

В общем не используйте интерфейсы ради интерфейсов и не получите лишних проблем.
Есть код среднего по размерам проекта, можете оценить как в нём писали код. еще код
В редких случаях такой подход имеет смысл, например когда пишут кроссплатформенную либу для GUI или у вас на беке будет гарантированно несколько баз с одинаковыми методами, если у вас ситуация не требует этого, то не пихайте всё в один интерфейс. Интерфейс создан для удобства а не для того чтобы мучаться.

Вероятно таблица слишком большая и она просто в отдельном окне отображается, когда нажимаешь esc окно закрывается, если вывод от запроса маленький то отображение идёт сразу в окно с клиентом.

По какой то причине данный код раз от раза при попытке добавления данных в БД выдаёт исключение о том, что был факт попытки добавления некорректного ("неуникального", если угодно) ключа.

Скоре всего одно из значений это primary key или unique, поэтому и кидает ошибку.

Также существует проблема что уже для добавленных данных подбирался id немного не по порядку:

Это фича у постгреса такая, но в целом если подумать, то это не особо и нужно, чтобы id шли по порядку.

Вот так

select * from query_to_xml('select * from table_name',true,false,'');

ответ