كيف تعمل خاصية spring.jpa.hibernate.ddl-auto بالضبط في Spring؟
database-connection (1)
كنت أعمل في مشروع تطبيق تمهيد Spring الخاص بي ولاحظت أنه في بعض الأحيان يوجد خطأ في مهلة الاتصال بقاعدة البيانات الخاصة بي على خادم آخر (SQL Server).
يحدث هذا بشكل خاص عندما أحاول القيام
FlyWay
بعض النصوص باستخدام
FlyWay
ولكنه يعمل بعد عدة محاولات.
ثم لاحظت أنني لم
spring.jpa.hibernate.ddl-auto
في ملف الخصائص الخاص بي.
قمت ببعض الأبحاث ووجدت أنه يوصى بإضافة
spring.jpa.hibernate.ddl-auto= create-drop
في التطوير.
وتغييره إلى:
spring.jpa.hibernate.ddl-auto= none
في الإنتاج.
لكنني لم أفهم بالفعل كيف يعمل حقًا وكيف يُنشئ السبات مخطط قاعدة البيانات باستخدام قيمة
create-drop
أو
none
قيمة.
هل يمكن أن توضح من الناحية الفنية كيف تعمل حقًا ، وما هي التوصيات باستخدام هذه الخاصية في خادم التطوير والإنتاج.
شكرا لك
بالنسبة للسجل ، فإن
spring.jpa.hibernate.ddl-auto
هي Spring Data JPA خاصة وهي طريقة لتحديد قيمة سيتم تمريرها في النهاية إلى Hibernate تحت الخاصية التي يعرفها ،
hibernate.hbm2ddl.auto
.
تؤثر القيم التي يتم تكوينها
create-drop
validate
منها
update
بشكل أساسي على كيفية قيام إدارة أداة المخطط بمعالجة مخطط قاعدة البيانات عند بدء التشغيل.
على سبيل المثال ، ستقوم عملية
update
بالاستعلام عن واجهة برمجة التطبيقات الخاصة ببرنامج تشغيل JDBC للحصول على البيانات الأولية لقاعدة البيانات ، ثم يقوم Hibernate بمقارنة نموذج الكائن الذي يقوم بإنشائه استنادًا إلى قراءة الفئات المشروحة أو تعيينات XML لـ HBM وسيحاول ضبط المخطط أثناء التنقل.
ستحاول عملية
update
على سبيل المثال إضافة أعمدة أو قيود جديدة ، ولكنها لن تزيل أبدًا عمودًا أو قيدًا قد يكون موجودًا من قبل ولكن لم تعد موجودة كجزء من طراز الكائن من التشغيل السابق.
عادةً في سيناريوهات حالة الاختبار ، من المحتمل أنك ستستخدم
create-drop
بحيث يمكنك إنشاء المخطط الخاص بك ، تضيف حالة الاختبار الخاصة بك بعض البيانات وهمية ، تقوم بتشغيل الاختبارات الخاصة بك ، ثم أثناء تنظيف حالة الاختبار ، يتم إسقاط كائنات المخطط ، وترك قاعدة بيانات فارغة.
في التطوير ، من الشائع غالبًا رؤية المطورين يستخدمون
update
لتعديل المخطط تلقائيًا لإضافة إضافات جديدة عند إعادة التشغيل.
لكن مرة أخرى ، تفهم أن هذا لا يزيل عمودًا أو قيدًا قد يكون موجودًا من عمليات الإعدام السابقة التي لم تعد ضرورية.
في الإنتاج ، يوصى بشدة بعدم استخدام
none
أو ببساطة عدم تحديد هذه الخاصية.
ذلك لأنه من الممارسات الشائعة لمراجع قاعدة البيانات مراجعة نصوص الترحيل لتغييرات قاعدة البيانات ، خاصةً إذا كانت قاعدة البيانات الخاصة بك مشتركة عبر خدمات وتطبيقات متعددة.
