Software Development

What are the different values for hibernate hbm2ddl.auto and when should I use each one?

KI Asked by Kimberly Wright · 15-04-2024
0 upvotes 13,184 views 0 comments
The question

I am currently setting up a Java Spring Boot project and I'm a bit confused about the hibernate.hbm2ddl.auto configuration property. I know it handles the database schema generation, but I want to understand the exact behavior of all possible values like create, update, and validate. What are the best practices for using these in a development environment versus a production environment to ensure I don't accidentally lose any critical data?

3 answers

0
SA
Answered on 18-04-2024

The hbm2ddl.auto property is a powerful tool for managing your schema. The main values are:

  1. validate: Just checks if the schema matches the entities; it makes no changes.

  2. update: Updates the existing schema with changes (e.g., adding columns) but won't delete data.

  3. create: Drops existing tables and creates new ones every time the SessionFactory is created.

  4. create-drop: Similar to create, but also drops the tables when the application shuts down.

  5. none: Does nothing. In production, you should almost always use validate or none and handle migrations with tools like Liquibase or Flyway to prevent data loss.

0
ST
Answered on 20-04-2024

Are you finding that the update value occasionally fails to rename columns or handle complex constraint changes correctly in your local MySQL or PostgreSQL environment?

MI 22-04-2024

That is exactly what I'm seeing, Steven. When I rename a field in my Java entity, Hibernate's update just adds a new column instead of renaming the old one, leaving me with a mess of redundant data. Does this mean I should manually write SQL ALTER scripts for any change that isn't a simple addition, or is there a specific Hibernate configuration that can detect property renames more intelligently than the default setting?

0
BA
Answered on 25-04-2025

I always recommend using create-drop for unit tests and validate for everything else. It’s the safest way to ensure your code and database are in sync without risking a wipe.

KI 27-04-2024

I agree with Barbara. Relying on update in a shared dev database is a recipe for disaster because it often misses dropped constraints, leading to subtle bugs that are hard to track down.

Share your thoughts

Your email address will not be published. Required fields are marked (*)

Professional Counselling Session

Still have questions?
Schedule a free counselling session

Our experts are ready to help you with any questions about courses, admissions, or career paths. Get personalized guidance from industry professionals.

Request a Call Back

Search Online

We Accept

We Accept

Follow Us

"PMI®", "PMBOK®", "PMP®", "CAPM®" and "PMI-ACP®" are registered marks of the Project Management Institute, Inc. | "CSM", "CST" are Registered Trade Marks of The Scrum Alliance, USA. | COBIT® is a trademark of ISACA® registered in the United States and other countries.

Book Free Session