Allow for @Table annotations to use configuration parameters

[berlin-ab]

For example:

@table(schema="${myApp.schemaName}")

We have multiple applications which use the same database schema in production, but need to use different schemas in development. The @table annotation provided by hibernate-jpa accepts a schema, or can use a default schema from application.properties, but there isn't an easy way to configure these schemas dynamically. Schemas are fixed at compile time.

[philwebb]

It might be possible to hook into the way hibernate reads these values using a custom org.hibernate.annotations.common.reflection.AnnotationReader. It doesn't look like a particularly trivial task to wire this up.

These links might also help

http://stackoverflow.com/questions/2737420/how-to-set-up-default-schema-name-in-jpa-configuration

https://forum.hibernate.org/viewtopic.php?p=2265044#2265044

[berlin-ab]

We're using multiple schemas in our application, so using a default schema name doesn't quite help in our case.

[berlin-ab]

I think this will be a recurring issue for enterprise clients, especially those using Oracle. I'd really like to get a fix in for this so that we can have isolated tests between projects while having only one installation of Oracle. I'd prioritize this as higher priority than most other issues.

[philwebb]

I've assigned this for 1.1.0.M2, I'll try and take a look but we have a hard deadline for the 1.1 release so I might need to push it back again.

[dsyer]

What's wrong with spring.jpa.properties.hibernate.default_schema=${myApp.schemaName}? Surely you don't need more than one schema in a single app very often?

[berlin-ab]

@dsyer I definitely have a use-case of 2+ projects that have needed this feature.

[dsyer]

So why can't they use the Hibernate properties? Do they use multiple schemas?

[philwebb]

I may have a solution for this, but finding a way to hook into Hibernate turned out to be quite convoluted.

Prototype code is here:
https://github.com/philwebb/spring-boot/tree/gh-829

This adds a hook to process the Hibernate Configuration then replaces the annotation reader with a new version that can resolve placeholders. So far the only annotation attribute that I have registered is Table.schema, but others should also work if we want.

I'm in two minds if adding this is good idea or not, it seems like it could be quite brittle.

[dsyer]

My $0.02: Hibernate has had the @Table annotation for nearly ten years and no-one needed this feature yet. If it might be brittle we should be cautious and I haven't seen the code that needs it.

[philwebb]

I've found stackoverflow questions asking about this - just because it isn't supported by Hibernate doesn't mean it isn't wanted.

I'm not so familiar with the "Oracle way" when it comes to databases so I don't really know when or why you would want to use two schemas in a single application. Perhaps some more background on the underlying reasons would us help decide if we should put this in.

Just to be clear, the fragility of the code is because there is no obvious way to hook in a custom AnnotationReader. It will certainly work today, but if Hibernate change any internals it may break on an upgrade.

@berlin-ab If we don't put this into Boot, you can probably still crib the code and put it in your own library.

[berlin-ab]

@philwebb We were working with a client that had data stored across multiple Oracle schemas for different domains of their business. Some applications within their organization reach across schema boundaries.

We wanted the ability to configure schema names for our separate applications so that there wouldn't be any collision between them at runtime/migration time in development.