I have an issue for which I have a clean work-around, but I thought I would raise it to see whether I can learn what caused it.
I am using Hibernate 5.3.7.Final with PostgreSQL 42.2.2.jre7. I was using default entity names and table names when the problem began occurring. The problem was that Hibernate thought one of my tables didn’t exist.
If I asked Hibernate to validate my schema then it complained that the table didn’t exist, but if I asked Hibernate to update my schema then it tried to create the table and then complained that the table already existed. If I dropped my tables and asked Hibernate to update my schema then it created the tables without issue, but on the next execution it tried to create the table again and complained that it existed.
I solved the problem for the first table by setting entity and table names explicitly, at which point the issue moved on to another table. Eventually I set the table names and entity names explicitly for all of my entities and set the table name explicitly for the only non-entity collection table that Hibernate was creating, and the problem was gone, but I don’t know what caused the problem.
I was using Hibernate with default entity and table names as I developed my project. This problem only occurred after my first three entities and the collection table were implemented and working correctly, so I don’t think the issue is case sensitivity per se.
It was OK even with the fourth table until I changed the entity name of the entity for which the fourth table was created. When I roll back to a version with the fourth entity but before I renamed it, everything seems to work so I am guessing that is what broke it.
I have used Camel case Entity names throughout.
This is not a crisis as my work-around is serving me well, and maybe providing explicit names is a better practice regardless. Nevertheless, I would like to understand what happened. Any other thoughts?
It was OK even with the fourth table until I changed the entity name of the entity for which the fourth table was created. When I roll back to a version with the fourth entity but before I renamed it, everything seems to work so I am guessing that is what broke it.
I didn’t understand this part. It’s not clear what was working and what is not, and what exactly do you mean by rolling back.
The only way to understand this issue is if you replicate it with this test case template. We can analyze the test case afterward and tell you what’s wrong with it.
I am able to reproduce this behavior with a single table. Hibernate is not creating the database, but it is creating the table.
I have dropped my table and let Hibernate recreate it (which it does without issue) many times while I have been investigating this behavior.
I am using:
XXX
If XXX is “update” and I have started with no table then Hibernate will create my table as expected.
If XXX is “validate” and the table exists then Hibernate will unexpectedly throw an exception indicating that my table (“relation”) doesn’t exist:
Exception in thread “main” org.hibernate.tool.schema.spi.SchemaManagementException: Schema-validation: missing table [Koko]
If XXX is “update” and the table exists then Hibernate will try to create it and PostgreSQL will as expected throw a duplicate table exception:
org.hibernate.tool.schema.spi.CommandAcceptanceException: Error executing DDL “create table Koko (koko_id int8 not null, createdOn timestamp, description varchar(255), kokoName varchar(255), mainPhotoId varchar(255), mainPhotoName varchar(255), type varchar(255), primary key (koko_id))” via JDBC Statement
.
.
.
Caused by: org.postgresql.util.PSQLException: ERROR: relation “koko” already exists
.
.
.
I am trying to adapt my test case to the HIbernate test case template, but it is slow going. At the moment I am looking for:
Thanks, Vlad. I will give that a try, although it may be an uphill struggle as I use Eclipse.
Meanwhile I have refined the work-around: It isn’t necessary for me to name the entity explicitly; I only have to name the table. The name I give it is the name that Hibernate gives it when left to its own devices, but it all works correctly if I provide the name.
I was a little suspicious of my DAO as it is built using a pattern I have never used before, so I factored it out of my test case and the problem remains. My guess is that the problem stems from some little glitch in the PostgresSQL-specific code, but that is just a guess.
Factoring out the DAO had the added benefit of allowing me to reduce the test case to just two classes: a trivial domain class and a trivial test program, plus my Hibernate config.
I thought about why it worked and then stopped working, and I decided to try it in a new database. Worked fine. So I guess my first database has become corrupted in some way.