Наше приложение различает данные для конкретного «пользователя» (на самом деле это юридическое лицо, но мы будем называть его пользователем для простоты) и данные, которыми обмениваются все пользователи. Требуется, чтобы пользовательские данные хранились в отдельной схеме для каждого пользователя. Таким образом, есть данные, которые являются общими и совместно используются в схеме, к которой могут получить доступ все пользователи, и ряд схем, каждая из которых может быть доступна только тому пользователю, к которому она относится. Каждая из этих пользовательских схем будет содержать один и тот же набор таблиц, поэтому у нас может быть что-то вроде USERA.ACCOUNT, USERB.ACCOUNT (и т. д.) и SHARED.PRODUCT в общей схеме. Мы добились этого и создали что-то, что вполне соответствует требованиям, указав @Table(schema="SHARED") для типов сущностей, представляющих общие данные. Мы не указываем схему для типов сущностей «пользователь» — выбор схемы для поиска остается за DAO. У нас есть один DAO на пользователя, каждый из которых настроен на использование соответствующей пользовательской схемы и выбирается на основе пользовательского «контекста», связанного с любой данной операцией.
Пока все хорошо, но имя общей схемы теперь жестко закодировано в файлах классов сущностей для общих типов данных. И поскольку он находится в аннотации, он скомпилирован в них. Это нехорошо для нас, поскольку обычно при развертывании на клиентских сайтах мы обнаруживаем, что клиентский администратор базы данных хочет диктовать имена схем, но мы не хотим перекомпилировать для этого. Хуже того, на клиентском сайте у нас обычно было бы несколько систем для разных целей с разными именами схем (PROD, UAT и т. д.), и делать это с использованием нескольких перекомпилированных копий одной и той же системы было бы безумием.
Мне не удалось найти способ переопределить схему, определенную в аннотации. Кто-нибудь знает способ добиться этого? Я попытался перенести нашу систему с прямого использования спящего режима (SessionFactory и т. д.) на JPA (EntityManagers и т. д.), поскольку это в принципе позволяет переопределить атрибут схемы в аннотации записью в ORM.xml, но, похоже, мир проблем с использованием JPA/JTA/Spring, из-за которых операции в жизненном цикле транзакции, такие как сброс, больше не происходят, как вы ожидаете, поэтому я отказался от этого.
Любые предложения будут приветствоваться...