аувв,

Настройки объединяются в 3 группы.
- Настройки текущего состояния сервера. Хранятся в базе. Спокойно переносятся между версиями.
- Настройки текущей версии приложения. Хранятся в приложении. Спокойно переносятся между серверами и мигрируются в новых версиях без проблем.
- Настройки соединения с базой, хранятся в сервере приложений. Приложение спокойно переносится между серверами.

Вроде всё просто. У вас какие-то особые "настройки" и они не в одну из групп не попадают?

ауввнапример, в третью группу у меня попадает настройка маппинга hibernate.
Ошибочно попадают.

аувву меня файл hibernate.hbm.xml лежит в пап... директории src\main\resources.
То есть можно считать что в исходниках.

аувв


А это зачем?

аувв вот мой вопрос: куда бы мне этот hibernate.hbm.xml положить.
В приложение. Это 2я группа.

ауввэто настройка базы.
Нет. Это настройка ORM.

ауввона чуть-чуть разная для каждой инсталляции.
Таки для каждой? Или, если подумать, то разница только в диалекте SQL и типах?

ауввнет, в каждой инсталляции бывают разные одно-два поля в паре таблиц.

А если сделать над собой усилие и попытаться объяснить зачем так, то можно будет подумать и принять решение к чему именно эти настройки отосятся.

ауввто есть, в моем случае это - настройка приложения и третья группа. буду благодарен, если вы или кто-то другой мне поможет с такими условиями.
То есть. Реально, на UAT, QA, у каждого Developer-а и в каждом экземпляре Production - везде абсолютно разная структура определенных таблиц? Или как? Объясните, или продолжать угадывать?

ауввя принял решение - к третьему типу из вашего списка. вопрос не в том, к какому типу относятся настройки. вопрос, как мне именно эти настройки сделать настройками третьего типа.
Это очень радостно. Но как вам помочь, не понимая нюансов и требований? Обычно в таких случаях на все советы я получаю ответ вида "мне не подходит, потому что у меня ещё одно непреодолимое требование, которое я не сочел нужным упомянуть ранее".

аувву каждого клиента. кроме того, клиенту (его админам) предлагается самому немного менять схему данных.
Хорошо. Тогда возникает вопрос каким образом это связано с ORM который не предполагает динамической схемы принципиально. И исходня из этого возникает рецепт - разделять ORM маппинг и то что связано с динамической моделью.

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

ауввгде часть схемы закрыта от редактирования клиентом, а в остальном отсутствуют ограничения, обычно накладываемые всякими редакторами database-aware форм типа seibel или там 1с? за это я тоже был бы благодарен, потому что ничего лучше, скажем, интерфейса sql server management studio или аналогичного для oracle для описания схемы я пока не видел, но она, естественно, не защищает от админа-дурака.
Почему бы не разделить всё это богатство на два namespace или схемы? Мне всё ещё не понятно почему ORM применяется для динамической схемы? Вы потом классы генерите и отдаёте клиету?

аувва сами они порождают тупейшие create table или хранят все в entity-attribute-value структуре, которой потом пользоваться невозможно, замучаешься джоинить.
Это правильно. Просто теперь стало совсем не понятно, зачем тут ORM.

аувввпрочем, можно не вступать в дискусию на тему "понимаю ли я что делаю", а просто подсказать, как мне вынести настройку схемы/маппинга и положить ее рядом с приложением
Динамическая схема, мапиться на динамические классы, которые потом кто использует?

ауввдалее, схема мапится не на динамические классы, а на родной java.util.Map, с помощью этого:

Ну, вот, это же уже разговор по делу.

аувв> Почему бы не разделить всё это богатство на два namespace или схемы?
не очень представляю, как. у одного клиента требование ФИО, а другой хочет еще титул и обращение. легче всего, чтобы у каждого была своя версия таблицы person.

В любом случае выходит есть разные hbm файлы. Одни для статической модели. И отдельный файл, для динамической модели, который можно хранить где угодно (даже CLOB-ом в базе). Собсветнно это 1й пункт, а не 3й, как вы ошибочно приняли решение. Если файл хранить отдельно от базы, его нужно переносить вместе с бекапами базы. А если хранить в базе и загружать предварительно через JDBC, то проблемы переместимости быза данных не будет.

ауввони

Ну, теперь-то вырисовывается более менее стройная картина. Всего лишь надо было нормально объяснить.

ауввну что не так?? =)
Всё так. Храните этот конфиг CLOB-ом в базе. Загружате перед конфигурацией Hibernate и добавляте в конфигурацию хоть через Hibernate API, хоть через Spring.

аувва какие волшебные слова мне надо написать в applicationContext для этого?
Можно скачивать из базы в файловую систему и добавить ресурс как file://
Можно посмотреть исходник\доку LocalSessionFactoryBean разобраться с там как добавить динамически Resource, например InputStreamResource или ByteArrayResource. Сделать свой наследник этого класса с init методом, который бы создавал такой ресурс и добавлял к другим указаным в Spring.