EntityManagerFactoryBuilder does not apply spring.jpa.hibernate customizations automatically

[eepstein]

When using a single data source and entity manager in a Spring Boot JPA project, the hibernate settings are picked up from the application properties (e.g., the application.yml file) and applied as expected.

In the case of multiple data source and entity managers, the naming_strategy setting is not applied and thus we get the default naming strategy. A minor bug with a likely quick fix I imagine.

I've put together a sample project showing the issue:

https://github.com/eepstein/multids-demo

(which was forked from https://github.com/gratiartis/multids-demo)

The relevant lines are in the FooConfig and BarConfig classes. For example, from com.sctrcd.multidsdemo.integration.config.foo.FooConfig:

                    // This is to work-around a bug in Spring boot, which is not setting the naming strategy when there
                    // are multiple data sources and entity managers.
            .properties(Collections.singletonMap("hibernate.ejb.naming_strategy",
                    jpaProperties.getHibernate().getNamingStrategy()))

If you comment out that line you'll see an assertion in the test will fail, even though the naming strategy is being correctly set in the application-test.yml file in the test resources folder.

[snicoll]

Thanks for the sample!

Well you are creating the EntityManager yourself so there is no magic. Spring Boot can't intercept that and apply the naming strategy. We have a related issue to create a sample using two database (#3456) so we could use your sample as a base to show you what needs to be done

(and maybe fix a bug or two along the way 😄 )

[eepstein]

Curiously all the other attributes are set automagically via the builders. This is true for both the DataSource and the EntityManagerFactory. Plus, the value in question is available via the autowired JpaProperties (which is automatically created by the spring-boot packages). So, I think this is a bug (or missing feature if you prefer).

There is a need to slap an @primary on one of the DataSource instances or else spring complains. But otherwise, and except for the naming_strategy, everything gets wired up from the config/properties file with zero intervention. I'm of the opinion that naming_strategy should be included in that default auto-wiring.

[snicoll]

Compare our LocalContainerEntityManagerFactoryBean and yours.

I haven't looked deeper than that but it's fairly different IMO. It's not a terminology problem (I don't have a problem calling something a bug when there is one). I just think your configuration is different. Maybe we can also fix that via a template method. I'll have a look.

[eepstein]

Hi Stéphane,

So, this becomes a usage question on my end. How do I configure things so that the HibernateJpaAutoConfiguration is configured and used in the BarConfig class ? In particular, what's the recommended way to get or setup the EntityManagerFactory so that it is configured with all the vendor-specific settings (Hibernate in this case)?

(I see how to do so for the primary data source. What's unclear is how to leverage that code for a secondary or tertiary data source. In my particular case I go a semi-custom route, but then I'm not using JTA, not using WebSphere, and not using an alternate vendor/provider. In short, would be nice if eithe some of the protected methods were public, or if the configuration methods took a datasource so that the subsequent layers could be configured using all the logic embedded in the existing Spring code.)

Thank you.

[snicoll]

Hi @eepstein, no worries! I am not sure yet. I'll have a look tomorrow morning. Cheers!

[eepstein]

Perhaps XML config is the way to go in this case?

[snicoll]

What leads you to such conclusion? I haven't looked at it yet (last minute M3 stuff kept me busy)

[snicoll]

Okay so I have a good overview of the problem now.

I have created a sample that exposes several steps. You can browse the initial version that is similar to what you end up doing.

Like I said, you are creating the entity manager yourself so any customization that is done in the auto-configuration is lost (since you are overriding it). One of these customizations is to auto-detect the hbm2ddl.auto mode (i.e. enable create if the database is embedded). The other customization is to set the naming strategy to a sensible value if none was defined. If you look at the Hibernate customizations of JpaProperties there are two fields really and these are the ones that are customized.

I am not sure I understand why we don't apply these in the builder since we have everything that we need. I'll probably change that.

You can workaround the issue by specifying the following in your configuration

spring.jpa.properties.hibernate.ejb.naming_strategy=FooBar

Now, what I find a bit disturbing about this setup is that the JPA settings are shared between the two persistence units. What if you want different settings? To demonstrate this, I have completely disabled the auto-configuration and created a two sets of JpaProperties (each on their own namespace)

Finally, that project also showcases how you can generate the relevant meta-data for those new keys so that you get content assistance in the IDE. I hope that helps.

TL;DR the builder should apply the customization internally, I see no reason why it doesn't do it but keep in mind that since you are overriding things, it is normal that you lose some of the auto-magic features.

[eepstein]

Hi Stéphane,

So some of that lines up with my own observations and conclusions and some is either new or didn't line up with my own explorations and I'm not sure what I should have done instead. So, in no particular order:

• I expected the Builder to have all the default settings baked in, and loaded from the properties. In short I expected it to be more like the DataSourceBuilder. It actually seems that the EntityManagerFactoryBuilder does have some things baked in and others not. This latter is what originally led me to open the issue.
• I agree about the single JpaProperties. In my particular case it works as the values are shared, but in general something like what's in your sample is the way I'd choose to go.
• I set the spring.jpa.properties.hibernate.ejb.naming_strategy and it had no effect unless applied manually to the builder. As mentioned this was the original reason for opening the issue. Also, although the property name on the hibernate side is hibernate.ejb.naming_strategy, the common way to set it via spring is just: spring.jpa.hibernate.naming_strategy (no "properties" and no "ejb" in the name). It (sort of) matters, since the common way to configure things when there is a single data source and single entity manager is with the shorter name ... and, again, would be nice if the same worked when there are multiple DSs & EMs
• What I had before is working well now. In fact changed it to apply all the hibernate properties and changed also to use the regular Spring Boot classes for the primary data source and entity manager creation. Not ideal, but didn't feel like going the copy & paste route. May follow what you've done instead.

Should I look for an enhanced builder or some template method in a subsequent release?