We Keep Coding

Spring Data JPA creates two tables after renaming entity

I'm using Spring Boot 2.6.4 and Java 17. And I previously had an Entity called BlogPostComment but recently decided that just Comment is more concise. I don't have a data.sql file to explicitly create tables and let Hibernate handle all the database operations for me. So I'm expecting that the table previously named blog_post_comment would be renamed as comment. However, when I rerun my application after renaming the entity, Hibernate creates two tables blog_post_comment and comment instead of just the latter.
Before renaming:
#Entity
public class BlogPostComment { ... }
After renaming:
#Entity
public class Comment { ... }
I've tried adding #Table(name = "comment") annotation to this entity, but Hibernate created the table with the old name all the same. And I've also tried invalidating IntelliJ IDEA caches, still did not solve this problem. Please help me identify the cause of this error, thank you.

It is possible that your hibernate.hbm2ddl.auto property in application.properties is set to none . What none does is that no action is performed. The schema will not be generated. Hence your changes will appear as a new table in your database. What you should do then is to set the property to update and then run the application. What update does is that the database schema will be updated by comparing the existing database schema with the entity mappings.
PS: If no property is defined, the default property is none. You should add the property and set to update

I strongly doubt that Hibernate creates a blog_post_comment table after you renamed the entity. I suspect this is just still around from the previous run.
Hibernate (or any other JPA implementation) does not know about you renaming the entity. It has no knowledge what so ever about the entities present during the last start of the application. Therefore it doesn't know that there is a relationship between the existing blog_post_comment table in the database and the not yet present comment table it is about to create.
When Hibernate "updates" a schema it checks if a required table already exists and if so it modifies it to match what is required by the entities. But even then it won't rename columns, it would just create new ones.
In generally you should use Hibernates schema creation feature only during development and never for actually deploying a schema into production or even worse, updating a schema in production. For this you should use specialised tools like Flyway or Liquibase which exist for exactly this purpose.

How to get Hibernate to ignore table columns not in entity?

I'm using Java with Spring MVC and Hibernate. I have a bunch of entities and everything works fine. If, however, I add a column to one of my database columns, my service will start crashing until I also update the relevant java entity class with the new column.
Is there a way to tell Hibernate to ignore database columns it doesn't recognize? If you want to have a field in your entity that's not in your DB table, you would use #Transient on the field. I want the inverse of that.
If this is not possible, how do Hibernate services get deployed when there's a database update that has to go along with it?

Hibernate will not "crash" after new columns were added to a table managed by Hibernate. Hibernate scheme validation goes only as far as verifying that the mapped columns can be stored in the database, but will not look for unmapped columns in the database.
What is likely causing your problem is a new NOT-null field. Adding such a field will make it impossible for Hibernate to persist anything into that table since it is oblivious to the existence of this field and will not provide it at insertion-time. Solutions to this problem are:
Providing DEFAULT in the alter table operation for clients that do not use this field
Not marking the field not-null and performing nullability checks in another layer
Using pre-insert triggers to populate the empty fields
Alternatively you can even add the new field first, deploy your new version of your application, then mark the new field as not-null.

Configuring Hibernate to play nice with existing DB constraints?

The last few days I've rolled up my sleeves and dug into Hibernate for the first time. I was very surprised to learn that Hibernate's default behavior is to actually drive the DDL of the database itself:
<property name="hbm2ddl.auto">create</property>
or
<property name="hbm2ddl.auto">update</property>
This is opposite of what I'm used to, where someone (usually a DBA) creates the database structure: the schemas, the table, the key constraints, the indexes, triggers, etc; and then I (the developer) code my app to abide those constraints.
This raises a few similarly-related questions:
How are indexes created/maintained in conjunction with a Hibernate-based app? Pick your favorite relational DB - MySQL, Postgres, Oracle, anything. Do you specify indexes through Hibernate (and if so, how), or do you have to specify them in the DB (and if so, how do you get Hibernate to honor such indexes and not overwrite them)?
Same question as #1 above, but with multi-column keys instead of indexes.
How do you specify column order in Hibernate? Is it just based on the order of the Java fields inside the entity? What about columns that Hibernate adds (such as when doing joins or implementing inheritance strategies)?
If I manuall install a trigger on a table that Hibernate created, how do I prevent Hibernate from overwriting/deleting it?
How do I specify what DB/schema a Hibernate table gets created in?
Thanks in advance!

You can use #Index annotation on your entity field
Please see this question / answer: How to define index by several columns in hibernate entity?
Yes it's just based on the order of Java fields in the entity
You can set hbm2ddl.auto to "validate" to make it just validate your schema, without making any updates.
You can use #Table(name = "..") annotation to specify custom name for your entity/table

Using criteria-api to dynamic tables

I use criteria-api to made sql query to the database and it work very fine.
But now I need to use dynamic tables , where some tables can be create or destroyed and some column can be add or removed.
I want to manage this entityties in dynamicBean of apache, then I can create bean and edit the column.
How can I made a sql sentece using criteria-api if the bean is not in the file persistence.xml and if it is a dynamic bean?

Not sure on dynamic beans, but you may wish to investigate EclipseLink's dynamic entity support,
http://www.eclipse.org/eclipselink/documentation/2.4/solutions/softwareasaservice002.htm#BABFJDCF

JPA2/Hibernate - Creating a schema on the fly (ie without pre-create the schema manually)?

I use JPA 2 with Hibernate Entity Manager 3.6.4. Once I have marked my entities with various annotations (#Entity, #MappedSuperClass etc), I put in my persistence.xml file the default schema to use (hibernate.default_schema property).
I know it's possible to create automatically the objects contained in the schema.
But is it possible to create the schema itself automatically and then create the objects it contains ?
EDIT :
I use this parameter too : hibernate.hbm2ddl.auto, to tell Hibernate to create the schema if it doesn't exists yet. No luck, Hibernate doesn't create it !

I have googled a little bit and find this post : Hibernate hbm2ddl won't create schema before creating tables.
The fact that Hibernate does not create a schema before creating table is a bug. Other database suffer from this situation : H2, Postgresql etc.
This bug is planned to be fixed with 5.0.0 release of Hibernate.
So, for now, the only workaround is to create the schema by yourself, either manually or by a mean offered by your database vendor, since Hibernate can't do it itself :\

I managed to build a workaround that uses the hbm2ddl default flow.
Since it always calls the "database-object" drop statements BEFORE creating schema, you can do something like this:
<database-object>
<create></create>
<drop>DROP SCHEMA IF EXISTS myschema cascade; CREATE SCHEMA myschema</drop>
</database-object>
unfortunately the create clause is mandatory and sadly it's only executed AFTER schema creation, no matter what order you put it on cfg.xml, so I made it empty, that way you don't have errors trying to creating schema again (it was already created together with drop)