Integrator not compatible with Hibernate ORM 5.0.1 #96
Comments
|
Hibernate 5.x support would be great! @nvoxland any idea when work will start on supporting it? |
|
+1 to Hibernate 5.x support! |
|
+1 |
7 similar comments
|
+1 |
|
+1 |
|
+1 |
|
+1 |
|
+1 |
|
+1 |
|
+1 |
|
I started a lab repository based on liquibase-hibernate to support Hibernate 5.x. |
|
@jean-merelis 👍 🎉 |
|
@jean-merelis if you need help, I'm sure the JHipster community would be ready to code/test/debug! Just ping me on https://twitter.com/java_hipster |
|
+1 |
11 similar comments
|
+1 |
|
+1 |
|
+1 |
|
+1 |
|
+1 |
|
+1 |
|
+1 |
|
+1 |
|
+1 |
|
+1 |
|
+1 |
|
+10 😁 |
|
+1 |
1 similar comment
|
+1 |
|
I still have one thing to check and I'll be good to go. Hopefully this On 13 October 2016 at 15:51, Nathan Voxland notifications@github.com
|
|
Some bad news that need investigation. All this was tested on MySQL.
I can provide a demo project featuring these issues is needed. |
|
If you have an example you could attach, that would be great. It would help me see what the problems are. |
|
Will do that this afternoon On 18 October 2016 at 12:25, Nathan Voxland notifications@github.com
|
|
Try with this please: https://github.com/henri-tremblay/finaldemo. We can chat if needed. |
|
Thanks, that's an impressively nice setup for reproducing the issue. I'll take a look a bit during the upcoming day, but will look more tonight. |
|
Did you have a look? To prevent loosing time looking at it myself if you On 19 October 2016 at 10:05, Nathan Voxland notifications@github.com
|
|
Sorry I didn't get to it yesterday like I was hoping. Looking now, though. The checksum issue is related to a fix that went into 3.5.0 that adjusted the checksum logic to no longer include blank lines in csv files used by loadData, to make it more resilient. Unfortunately, that means that anyone that happens to have blank lines in their CSV files will get a validation error because they are now different. Your csv files have a trailing newline and so are effected. While I have a checksum version flag that can disable checking during an upgrade, it running without checksum validation can cause unexpected behavior and the version flag is global so making a more seamless upgrade for some would make a less seamless upgrade for others. I ended up leaving the validation error for people with a newline in their csv files in this case. The work-around is to either run something like "update databasechangelog set md5sum=null where description like "%loadData%" or add a any tag to the problem changeset. Is the csv files you have with the newline something everyone using jhipster will run into? Or is it relatively unique to you? |
|
Having changes in changelogs when upgrading Jhipster is quite common and you generally need to revert them anyway if you do it for an already deployed app. So I don't think this is a real issue. |
|
Oh, I just understood that it's on the checksum calculation so that's an harder issue. Forget my stupid comment... |
|
The csv files are common to any JHipster app btw |
|
Is there a jhipster-level "we are upgrading to a new version" flag where we could update the databasechangelog table to clear out potentially problematic changesets using the update clause I listed above? |
|
I pushed a fix for the sequence showing up in the mysql changelog. The different-format foreign key (no _ in the name) seems to be a change in how the naming strategies are working in hibernate 4.x vs. 5.x. See http://stackoverflow.com/questions/37062675/hibernate-5-1-x-naming-strategy-backward-compatible-with-hibernate-4-x The test example is using: hibernate.implicit_naming_strategy=org.springframework.boot.orm.jpa.hibernate.SpringImplicitNamingStrategy hibernate.physical_naming_strategy=org.springframework.boot.orm.jpa.hibernate.SpringPhysicalNamingStrategy which as far as I can tell are being used correctly. |
|
Thanks. I'll test the sequence. I'll check for the naming. About the checksum, yes, this is standard Jhipster. But it will also happen to anyone using a csv then. And having a final endline is quite standard. So I don't know what to think about it. We will still have to upgrade liquibase but I think a fix accepting the final endline would make everyone's life easier. |
|
1- I confirm that if there is no EOF endline in the CSV, the checksum is correct Or course, it still mean that if you had a endline and you migrate, you are doomed (meaning you need Can't you calculate the checksum the old way when databasechagelogs.liquibase is on a old version? |
|
2- I also confirm that the hibernate_sequence is not re-created. So that's fixed |
|
3- Hibernate has changed its naming strategy. I filed an (issue)[https://hibernate.atlassian.net/browse/HHH-11193] to see if that was meant to be. Meanwhile, I have two choices. One is to leave it like that. The other is to add a custom naming strategy in JHipster. Anyhow, there is nothing you can do about it. |
|
3- Hibernate has changed its naming strategy. I filed an [issue])https://hibernate.atlassian.net/browse/HHH-11193) to see if that was meant to be. Meanwhile, I have two choices. One is to leave it like that. The other is to add a custom naming strategy in JHipster. Anyhow, there is nothing you can do about it. |
|
Bottomline: I validate that everything is working perfectly. You can release whenever you want. |
|
The whole checksum handling logic is definitely part of my larger changes I'm working on for Liquibase 4 because it isn't flexible enough at this point. I do have a version as part of the checksum that I can use to say "this old checksum was computed differently, so just ignore it", but it's a global number so it just makes all the changeSets ignored. The other problem is that when I go into "we can't trust the old checksum" mode, then it breaks the runOnChange logic, doesn't catch actual unexpected changed changeSets, and causes some other similar unexpected behavior for users. Because of that I have to be careful about not changing checksum logic if at all possible, but when we end up needing to we have to decide between making it transparent for people whose checksums changed vs. affecting everyone. In this case, we ended up thinking that when we were adjusting the checksum logic to no longer care about whitespace, the selection of people with CSVs that have empty lines was small enough that it wasn't worth potentially causing problems for everyone else. If JHipster does have a lot of users with CSV files with a trailing newline, it is probably worth figuring out something to make it more transparent vs. making them add a to problem changeSets and/or running the update statement. I'm looking to see if I can see a good way to handle it in the liquibase code, but it will take a new liquibase release, not just a new liquibase-hibernate release. |
|
I will remove the newlines at EOF for future JHipster versions. But in fact, pretty much everyone use a final newline from what I know. So I'm a bit surprised that nobody complained. Anyway. When do you think you can release liquibase-hibernate? |
|
You don't have to worry about removing the EOF newlines since the liquibase change that caused the problem makes empty newlines now not a part of the checksum. So from now on it doesn't matter if there are newlines at the end or in the middle or anywhere else. Better and more consistent for everyone from now on. I'll release the new liquibase-hibernate version today. |
|
It has now been released as liquibase-hibernate5 3.6 |
|
@nvoxland thank you very much Nathan! I'm glad you could fix this, great work! |
|
@nvoxland awesome work and thanks! Any idea when it will be available on Maven Central? |
|
In my opinion if adding/removing newlines to CSV can ease your problem a Thanks & Regards, On Sat, Oct 22, 2016 at 2:55 AM, Nathan Voxland notifications@github.com
|
|
It should be working it's way through maven central. I pushed it to sonatype and they mirror it from there. |
|
It is available. Since yesterday at least. Le 26 oct. 2016 12:56 AM, "Nathan Voxland" notifications@github.com a
|
and others
The current Liquibase Hibernate Extension (
liquibase-hibernate4) is not compatible with Hibernate ORM 5.0.1.Here is the error report: AbstractMethodError in SessionFactoryImpl
Steve Ebersole said:
Also mentioned in Liquibase + Hibernate ORM 5.0
Here is Hibernate 5.0 Migration Guide
The text was updated successfully, but these errors were encountered: