حفظ البيانات باستخدام Spring Data JPA

أدّى المستودع الموجود في الذاكرة في الدرس السابق خدمة مفيدة: فقد سمح بتصميم الواجهة دون أن تفرض قاعدة البيانات شكل الاستجابات. وعلينا الآن استبداله بتخزين فعلي، وهنا تحديدًا تتراكم على معظم مشاريع Spring ديون تقنية طويلة الأمد.

الصعوبة لا تكمن في كتابة كيان (Entity) — فأربعة تعليقات توضيحية (annotations) تكفي — بل في إدراك أن أداة ORM تضع وسيطًا بين شيفرتك وبين SQL الذي يُنفَّذ فعليًا. لهذا الوسيط قواعده: فهو يتتبّع الكائنات داخل سياق الاستمرارية (persistence context)، ويقرّر وحده متى يكتب، ويحمّل العلاقات أو لا يحمّلها وفق إعدادات ضمنية، ولا ينفّذ معاملة إلا إذا مرّ الاستدعاء عبر المسار الصحيح. والمطوّر الذي يجهل هذه القواعد يكتب شيفرة تبدو صالحة للعمل لكنها تُنتج ثلاثمئة استعلام SQL في الاستدعاء الواحد، أو لا تحفظ شيئًا على الإطلاق دون أن تُطلق أي خطأ.

يُرسي هذا الدرس طبقة الاستمرارية في biblio-api — أي الكيانات Livre وAuteur وEmprunt — مع تسمية كل فخ لحظة ظهوره: التحميل EAGER الذي نظنّه عمليًا، وequals التي تُفسد المجموعات، و@Transactional التي لا تُطبَّق.

الكيان: jakarta وليس javax

يعتمد Spring Boot 3 على Jakarta EE 9 وما بعده. وقد تغيّرت حزمة (package) جميع تعليقات الاستمرارية التوضيحية. وهذا هو أكثر أخطاء النسخ واللصق شيوعًا، وعَرَضه مربك: يُترجَم الكيان دون مشكلة، لكن Hibernate يتجاهله تمامًا ويشتكي من «نوع غير مُدار».