Генерация SQL дизайнером для PG с учетом схем

[s-andrey]

Сейчас дизайнер не может генерировать SQL для конкретной схемы (все скрипты выполняются в public) и тем более случаются проблемы когда он пытается привести модель к бд, когда таблицы в нескольких схемах.
На данный момент мы видим 2 способа как поправить эту проблему, но каждый из них как имеет свои плюсы так и минусы и поэтому собираем информацию и мнения какое решение будет более полезным и удобным.

Варианты:
I. Добавить и считывать схему для стадии из AdvancedSettingsSQL

Плюсы

1. задаются один раз на всю стадию
2. нет проблем с сервисными таблицами

Минусы

1. ограничение что одна стадия - одна схема (мб это и не минус, а наоборот логичное разделение моделей)
2. чтобы нужные скрипты сгенерировались с первого раза надо или руками создать AdvancedSettingsSQL или сгенерить скрипт и файл с настройками поправить настройки и перегенерить скрипты

II. Указывать схему в storage <схема>.<таблица>

Плюсы

1. в одной стадии классы из разных схем
2. нет необходимости в AdvancedSettingsSQL (но не факт)

Минусы

1. в каждый класс надо прописывать storage (что мб привести к ошибкам когда забудут указать + надо дружить с ms это)
2. проблемы с сервисными таблицами (не понятно откуда они должны брать схему)

Так же по обоим вариантам есть вопросы по экстернел классам....

Мы больше склоняемся к первому варианту, пишите свои варианты, вопросы и идеи (по сути основной вопрос могут ли быть в одной стадии классы из разных схем)

[mao29]

Я за второй вариант, но с дополнениями для решения минусов:

1. Если в storage не указана схема (нет точки), генератор постгреса должен брать предполагать public
2. Не понял в чем эта проблема? Что библиотека с объектами сервисных типов не имеет в storage схемы? В постгресе это можно с помощью search_path решить. По дефолту сервисные можно в public складывать

Первый вариант неудобен старым проектам, а также тем, что придется нарезать на проекты в коде в соответствии со схемами в БД, а это далеко не всегда один к одному соответствие