คุณสมบัติ spring.jpa.hibernate.ddl-auto ทำงานอย่างไรใน Spring

130

ฉันกำลังทำงานกับโปรเจ็กต์ Spring boot ของฉันและสังเกตเห็นว่าบางครั้งมีข้อผิดพลาดการหมดเวลาการเชื่อมต่อไปยังฐานข้อมูลของฉันบนเซิร์ฟเวอร์อื่น (SQL Server) สิ่งนี้เกิดขึ้นเป็นพิเศษเมื่อฉันพยายามย้ายสคริปต์บางอย่างด้วยFlyWayแต่มันใช้งานได้หลังจากพยายามหลายครั้ง

จากนั้นฉันสังเกตว่าฉันไม่ได้ระบุ spring.jpa.hibernate.ddl-autoในไฟล์คุณสมบัติของฉัน ฉันได้ทำการวิจัยและพบว่ามีการแนะนำให้เพิ่ม spring.jpa.hibernate.ddl-auto= create-dropการพัฒนา และเปลี่ยนเป็น: spring.jpa.hibernate.ddl-auto= noneในการผลิต

แต่ฉันไม่เข้าใจจริงๆว่ามันทำงานอย่างไรและไฮเบอร์เนตสร้างสคีมาฐานข้อมูลโดยใช้create-dropหรือnoneค่าได้อย่างไร คุณช่วยอธิบายในทางเทคนิคได้ไหมว่ามันทำงานอย่างไรและคำแนะนำสำหรับการใช้คุณสมบัตินี้ในการพัฒนาและบนเซิร์ฟเวอร์ที่ใช้งานจริงคืออะไร ขอบคุณ

— METTAIBI
แหล่งที่มา

FWIW JPA 2.1 มีคุณสมบัติมาตรฐาน javax.persistence.schema-generation.database.action ดังนั้นคุณจึงไม่เห็นว่าจำเป็นต้องใช้คุณสมบัติเฉพาะของผู้ขาย JPA สำหรับการสร้างสคีมา

— Neil Stockton

@NeilStockton แนวคิดหนึ่งที่เรากำลังสำรวจด้วย Hibernate 6 คือความสามารถในการควบคุมการสร้างสคีมาที่แตกต่างกันตามหมวดหมู่ เช่นตาราง orm ของคุณอาจเป็นnoneแต่คุณอาจต้องการให้ Hibernate Search และ Envers ตารางของคุณถูกสร้างขึ้นโดยใช้updateเนื่องจากมีการจัดการภายในโดยโครงการเหล่านั้นและคุณไม่ต้องการจัดการด้วยตนเองด้วยตนเอง ตอนนี้เราควบคุมสิ่งนี้ทั่วโลกสำหรับตารางทั้งหมดโดยไม่คำนึงถึงที่มา / แหล่งที่มา นี่จะเป็นเหตุผลในการใช้ตัวเลือกเฉพาะผู้ขายเพิ่มเติมหากคุณต้องการใช้สิ่งนี้

— Naros

216

สำหรับเร็กคอร์ดspring.jpa.hibernate.ddl-autoคุณสมบัติคือ Spring Data JPA เฉพาะและเป็นวิธีการระบุค่าที่จะถูกส่งไปยัง Hibernate ภายใต้คุณสมบัติที่ทราบในhibernate.hbm2ddl.autoที่สุด

ค่าcreate, create-drop, validateและupdateพื้นมีผลต่อวิธีการจัดการเครื่องมือคีมาจะจัดการกับคีมาฐานข้อมูลที่เริ่มต้น

ตัวอย่างเช่นการupdateดำเนินการจะสอบถาม API ของไดรเวอร์ JDBC เพื่อรับข้อมูลเมตาของฐานข้อมูลจากนั้นไฮเบอร์เนตจะเปรียบเทียบโมเดลอ็อบเจ็กต์ที่สร้างขึ้นตามการอ่านคลาสที่มีคำอธิบายประกอบของคุณหรือการแมป HBM XML และจะพยายามปรับสคีมาได้ทันที

updateการดำเนินการเช่นจะพยายามที่จะเพิ่มคอลัมน์ใหม่ จำกัด ฯลฯ แต่จะไม่ลบคอลัมน์หรือข้อ จำกัด ที่อาจมีอยู่ก่อนหน้านี้ แต่อีกไม่นานจะเป็นส่วนหนึ่งของรูปแบบวัตถุจากการทำงานก่อน

โดยทั่วไปในสถานการณ์กรณีทดสอบคุณน่าจะใช้create-dropเพื่อสร้างสคีมาของคุณกรณีทดสอบของคุณจะเพิ่มข้อมูลจำลองคุณเรียกใช้การทดสอบของคุณจากนั้นในระหว่างการล้างเคสทดสอบออบเจ็กต์สคีมาจะหลุดออกจากฐานข้อมูลที่ว่างเปล่า

ในการพัฒนามักจะเห็นนักพัฒนาใช้updateเพื่อแก้ไขสคีมาโดยอัตโนมัติเพื่อเพิ่มส่วนเสริมใหม่เมื่อรีสตาร์ท แต่โปรดเข้าใจอีกครั้งว่านี่ไม่ได้ลบคอลัมน์หรือข้อ จำกัด ที่อาจมีอยู่จากการดำเนินการก่อนหน้านี้ที่ไม่จำเป็นอีกต่อไป

ในการผลิตมักจะแนะนำให้คุณใช้noneหรือไม่ระบุคุณสมบัตินี้ นั่นเป็นเพราะเป็นเรื่องปกติที่ DBA จะตรวจสอบสคริปต์การย้ายข้อมูลสำหรับการเปลี่ยนแปลงฐานข้อมูลโดยเฉพาะอย่างยิ่งถ้าฐานข้อมูลของคุณมีการแชร์ในบริการและแอปพลิเคชันต่างๆ

— Naros
แหล่งที่มา

ใช่ไม่เคยใช้การสร้าง ddl ในการผลิต เราสร้างสคริปต์เริ่มต้นสำหรับโครงสร้างตารางโดยใช้ ddl และเกี่ยวข้องกับ DBA ในกระบวนการ จากนั้นเรารวมสคริปต์ db ไว้เป็นส่วนหนึ่งของหน่วยการปรับใช้และดำเนินการโดยใช้ Flyway เมื่อแอปพลิเคชันถูกปรับใช้ เมื่อเราต้องการแก้ไขฐานข้อมูลเราจะเพิ่มสคริปต์ใหม่ในแอปพลิเคชันเวอร์ชันถัดไปและปรับใช้กับการจัดเตรียม Flyway จะตรวจหาเวอร์ชันปัจจุบันโดยอัตโนมัติและเรียกใช้สคริปต์ที่จำเป็นในการนำฐานข้อมูลไปสู่เวอร์ชันใหม่ล่าสุด หากทุกอย่างใช้งานได้เราปรับใช้กับการผลิต

— Klaus Groenbaek

จะเกิดอะไรขึ้นถ้าเราไม่ระบุคุณสมบัตินี้? ตัวอย่างเช่นฉันมี <bean id = "sessionFactory" class = "org.springframework.orm.hibernate5.LocalSessionFactoryBean"> ... <prop key = "hibernate.hbm2ddl.auto"> อัปเดต </prop> ของตัวเองฉันมีสิ่งนี้ และด้วยเหตุผลบางอย่างตารางของฉันจึงถูกทิ้งตลอดเวลาจนกระทั่งฉันเพิ่มคุณสมบัติดังกล่าวข้างต้น ;; ps: ขออภัยสำหรับตัวอย่างโค้ด)

— Ţîgan Ion

ทำไมไม่validateอยู่ใน Production Env?

— Shamal Karunarathne

แอปพลิเคชัน @ShamalKarunarathne สามารถใช้validateในการผลิตได้ แต่โดยทั่วไปแล้วควรเป็นการตั้งค่าที่คุณใช้ในสภาพแวดล้อมคุณภาพ / การทดสอบเพื่อตรวจสอบว่าสคริปต์ฐานข้อมูลที่คุณเขียนหรือใช้กับเครื่องมือย้ายฐานข้อมูลของคุณนั้นถูกต้อง อีกเหตุผลหนึ่งที่ไม่ควรใช้validateในการผลิตก็คืออาจเป็นปัญหาคอขวดในระหว่างขั้นตอนการเริ่มต้นแอปพลิเคชันของคุณโดยเฉพาะอย่างยิ่งถ้าโมเดลวัตถุของคุณมีขนาดค่อนข้างกว้างหรือมีปัจจัยอื่น ๆ ที่เกี่ยวข้องกับเครือข่ายเข้ามามีบทบาท

— Naros

หากไม่มีสแต็กที่แม่นยำติดตามยากที่จะคาดเดา อย่างไรก็ตามการคาดเดาครั้งแรกของฉันorderคือการตีความอย่างไม่ถูกต้องโดยตัวแยกวิเคราะห์ SQL เนื่องจากเป็นคีย์เวิร์ดหากไม่ได้รับการ Escape

— Naros