|
As indicated in the the corresponding ticket in Spring Framework's tracker, I think the involvement of Spring is only the messenger here. It basically produces a standard PersistenceUnitInfo and doesn't do any hacks by default. It seems to me that the fact that within integration tests, EntityManagerFactory instances are repeatedly created for the very same database and the EMF seemingly re-trying to adapt the schema. So it feels like it's more a problem of non-idempotency that gets revealed by running more than one integration test rather than by Spring Framework doing some non-standard things itself.
In fact, we're using standardized JPA means that have worked before. If they now break, I guess blaming Spring Framework is a bit weird. The case I have here does not use any of the newly introduced adaptions of Spring towards Hibernate 5 configuration. I am totally with you that the new integration probably needs some polishing. But here, it just uses standard JPA means as it did before – which worked before, and worked on Beta 2.
So what I am trying to say is: there's a Spring/JPA based app that works on Beta 2. The very same Spring/JPA app doesn't work on the current snapshots with Hibernate throwing exceptions. Would you agree that it's more likely that chances are high, that the change in behavior is triggered by the component that changed in between the two reference points?
Regarding the timing, it's all your decision. I'm just not sure you do yourself a favor in terms of adoption if every simple but non-trivial Spring and JPA based application is running into these issues when trying to upgrade to 5.0 final. The reason we're working with the snapshots already is to provide a seamless experience for Hibernate users upgrade and to help you iron out these before you go GA and break a lot of users. I am not here to blame anyone. I try to be a good OS citizen, consider the fact that a lot of JPA users use Hibernate, try to adapt to upcoming versions and report bugs I find.
I took the time and went through individual snapshots:
EM 5.0.0-20150429.004052-114 – Core 5.0.0-20150429.004041-113 -> works (last snapshot before Beta 2) EM 5.0.0-20150430.061149-115 – Core 5.0.0-20150430.061140-114 -> works (first snapshot after Beta 2) EM 5.0.0-20150501.205832-118 – Core 5.0.0-20150501.205823-117 -> breaks
I've analyzed the debug output and that seems to indicate that the commit introducing additional quoting for reserved names is the core difference between the executions (one of the commits here). Any chance that the quoting doesn't get applied during the checks whether a schema upgrade is actually necessary?
|