Как подменить схему базы данных в Entity Hibernate?

Question

[Павел Талайко]

Привет, друг. Хочу понять как правильно динамически менять схему в сущностях.

В dev среде DEV.EntityValue в прод PROD.EntityValue.
Не хотелось бы указывать @Table(name = "VALUES", schema = "DEV").

@Entity
@Table(name = "VALUES")
public class EntityValue extends BaseEntity  {}

Как решить данную проблему?
Да и в некоторых стендах нужно использовать сразу две схемы для разных сущностей. Помогите решить проблему!

Answer 1

[Dmitry Roo]

Остановись, друг! Ты явно не туда идешь!
Код не должен зависить от среды вообще. Это слишком сильная связанность.
Prod, test, qa, staging, dev (etc..) должны быть разделены на уровне конфигурации.

Comments

[Павел Талайко]

Верно!

Так, хочу чтобы просто прослойка dao не менялась, а обращение к БД было другое.
У меня на деве есть подключение к одной БД со схемой, а на проме другая бд и схема.

Логично, что сущности должны оставаться и меняться только transactionalManager и LocalContainerEntityManagerFactoryBean.

Правильно?

Только схемы как менять?

[Dmitry Roo]

Павел Талайко, схемы поменять есть куча способов:
1. Конфиги ап.сервера (если используется). Конфиг лежит спокойно себе на сервере, а вы только приложение деплоете.
2. Профили спринг.бута
3. Переменные окружения
4. Можно подпихивать файл с конфигом при деплое через сервер CI (если используется)
5. Можно предумать что-то экзотическое через сетевые маршруты...
и т.д...

[Павел Талайко]

Dmitry Roo, да, конфиги. default_schema и так далее. Кейс на самом деле следующий: одна база данных, а схемы разные:
И в приделах одного контекста нужно работать (user_scheme и something_scheme). При выкатке на прод должно стать так: две разные бд и каждая имеет свою схему.

Уверен что такой кейс можно реализовать программно. И да, это микросервисная архитектура и датасорс основной бд вынесен в общую либу дата. И не хотелось бы переопределять.

[Dmitry Roo]

Павел Талайко, ну датасорос у вас же примерно так определяется: jdbc:somesql://host:port/schema
Ну так и сделайте два датасорса.
На деве:
jdbc:somesql://devdb:port/schema1
jdbc:somesql://devdb:port/schema2
На проде:
jdbc:somesql://proddb1:port/schema1
jdbc:somesql://proddb2:port/schema2

[Максим Федоров]

Павел Талайко,

И в приделах одного контекста нужно работать (user_scheme и something_scheme). При выкатке на прод должно стать так: две разные бд и каждая имеет свою схему.

Что? всегда одна БД (локальная) в приложении и все
А какая именно - зависит от того, где это приложение развернуто и какой конфиг прописан ему

Несколько БД в одном приложении делают например для миграции проекта, объединении разных баз или для др целей, не для прода и дева :)

[Павел Талайко]

Максим Федоров, да, миграция данных.

Answer 2

[Орхан Гасанлы]

Здравствуйте!
Если я правильно понял, то у вас есть база, в которой есть 2 схемы. И в зависимости от профиля вы хотите переключать схемы?

Я вижу тут пару вариантов:
1) на уровне gradle || maven определить схемы.
https://stackoverflow.com/questions/47240702/jpa-e...
https://stackoverflow.com/questions/1149352/using-...

<profiles>
    <profile>
      <id>production</id>
      <properties>
        <schema.name>production_schema_name</schema.name>
      </properties>
    </profile>
    <profile>
      <id>test</id>
      <properties>
        <schema.name>test_schema_name</schema.name>
      </properties>
    </profile>
</profiles>

2) использовать различные БД для разных профилей. Т.е. создать 2 БД по одной для каждого профиля.
3) Создать 2 пакета (dev, prod) с сущностями, где для каждой из сущностей указывать:
Для сущностей development
@Table(name = "VALUES", schema = "DEV").
Для сущностей production
@Table(name = "VALUES", schema = "PROD").
Ну и использовать аннотацию @Profile

Answer 3

[mystifier]

Как вариант можно создать Interceptor - наследник org.hibernate.EmptyInterceptor и в методе onPrepareStatement подменять хоть схему, хоть имя таблицы . Для этого нужно, чтобы была информация о профиле сборки(dev/prod).