Reputation: 3571
I was working on my Spring boot app project and noticed that, sometimes there is a connection time out error to my Database on another server(SQL Server).
This happens specially when I try to do some script migration with FlyWay
but it works after several tries.
Then I noticed that I didn't specify spring.jpa.hibernate.ddl-auto
in my properties file. I did some research and found that it is recommended to add
spring.jpa.hibernate.ddl-auto= create-drop
in development.
And change it to: spring.jpa.hibernate.ddl-auto= none
in production.
But I didn't actually understand how does it really work and how does hibernate generate database schema using create-drop
or none
value. Can you please explain technically how does it really work, and what are recommendations for using this property in development and on a production server.
Thank you
Upvotes: 327
Views: 582612
Reputation:
In Spring/Spring-Boot, SQL database can be initialized in different ways depending on what your stack is.
From Spring docs:
JPA has features for DDL generation, and these can be set up to run on startup against the database. This is controlled through two external properties:
spring.jpa.generate-ddl
(boolean) switches the feature on and off and is vendor independent.spring.jpa.hibernate.ddl-auto
(enum) is a Hibernate feature that controls the behavior in a more fine-grained way. See below for more detail.
From Baeldung:
Hibernate property values are: create, update, create-drop, validate and none:
- create – Hibernate first drops existing tables, then creates new tables
- update – the object model created based on the mappings (annotations or XML) is compared with the existing schema, and then Hibernate updates the schema according to the diff. It never deletes the existing tables or columns even if they are no more required by the application
- create-drop – similar to create, with the addition that Hibernate will drop the database after all operations are completed. Typically used for unit testing
- validate – Hibernate only validates whether the tables and columns exist, otherwise it throws an exception
- none – this value effectively turns off the DDL generation
Spring Boot internally defaults this parameter value to create-drop if no schema manager has been detected, otherwise none for all other cases.
Upvotes: 77
Reputation: 1227
According to spring documentation,
You can set spring.jpa.hibernate.ddl-auto explicitly and the standard Hibernate property values are none, validate, update, create-drop. Spring Boot chooses a default value for you based on whether it thinks your database is embedded (default create-drop) or not (default none).
In development, setting this property to create-drop
confirms automatic schema creation each time the app starts, aligning the schema with entity mappings. This setting is useful for rapid development, testing and preventing issues with outdated schemas.
In production, setting it to none
ensures schema stability and prevents accidental data loss. Disabling automatic schema management in production helps maintain data integrity and minimizes schema-related issues.
Upvotes: 1
Reputation: 177
spring.jpa.hibernate.ddl-auto=create-drop
means that when the server runs, the database instance is created. And whenever the server stops, the database table instance is dropped.
Upvotes: 3
Reputation: 4281
Also depending on spring.jpa.hibernate.ddl-auto
the DML files feature is enabled
It is worth to understand the difference between them.
Basically there are 3 types of database schema creating(DDL) and importing data(DML):
This topic covers Hibernate and it's DDL (first option), but it is worth to mention Hibernate DML files feature that enabled if spring.jpa.hibernate.ddl-auto
is create
or create-drop
That means import.sql
in the root of the classpath will be executed on startup by Hibernate. This can be useful for demos and for testing if you are careful, but probably not something you want to be on the classpath in production. It is a Hibernate feature (nothing to do with Spring).
Also here is a table that explains spring.jpa.hibernate.ddl-auto
and whether the import.sql
can be used depending on spring.jpa.hibernate.ddl-auto
value specified:
spring.jpa.hibernate.ddl-auto | Create schema from entities | import.sql |
---|---|---|
create | true | true |
update | update schema from entities | false |
create-drop | true | true |
validate | false | false |
none | false | false |
Also some extra information about different types of DDL amd DML can be found in Spring docs
Upvotes: 16
Reputation: 71
For the Propertie of JPA/Hibernate spring.jpa.hibernate.ddl-auto value should be create, update, create-drop not other then it will give an exception, where the correct meaning for these value -
Create : when the server will start all entity will be newly created
Update : when the server will start container will find which entities are update and which all are newly created the same thing will happen inside database as well old table will update as per the entity and newly table will created
Create-drop: when the server will start then auto all entity will crete and when the server will stop all the entities will auto remove from database
none : it means database ddl will not impact from back-end application Note: Production environment always set with none value
Upvotes: 6
Reputation: 21153
For the record, the spring.jpa.hibernate.ddl-auto
property is Spring Data JPA specific and is their way to specify a value that will eventually be passed to Hibernate under the property it knows, hibernate.hbm2ddl.auto
.
The values create
, create-drop
, validate
, and update
basically influence how the schema tool management will manipulate the database schema at startup.
For example, the update
operation will query the JDBC driver's API to get the database metadata and then Hibernate compares the object model it creates based on reading your annotated classes or HBM XML mappings and will attempt to adjust the schema on-the-fly.
The update
operation for example will attempt to add new columns, constraints, etc but will never remove a column or constraint that may have existed previously but no longer does as part of the object model from a prior run.
Typically in test case scenarios, you'll likely use create-drop
so that you create your schema, your test case adds some mock data, you run your tests, and then during the test case cleanup, the schema objects are dropped, leaving an empty database.
In development, it's often common to see developers use update
to automatically modify the schema to add new additions upon restart. But again understand, this does not remove a column or constraint that may exist from previous executions that is no longer necessary.
In production, it's often highly recommended you use none
or simply don't specify this property. That is because it's common practice for DBAs to review migration scripts for database changes, particularly if your database is shared across multiple services and applications.
Upvotes: 502