JPQL وCriteria API

لا تغطي entityManager.find() سوى حاجة واحدة: استرجاع كيان نعرف معرّفه. أما كل ما عدا ذلك، من بحث وتصفية وفرز وتجميع وربط، فيمرّ عبر استعلام. تقدّم JPA شكلين للاستعلام، والاختيار بينهما ليس مسألة ذوق.

JPQL لغة نصية تشبه SQL لكنها ليست SQL. هذا الفرق جوهري، وتكفي جملة واحدة لبيانه: JPQL تستعلم النموذج الكائني، لا المخطط (schema). تكتب select l from Livre l where l.auteur.nom = :nom، وHibernate هو الذي يقرر أن الأمر يتطلب ربطًا (join) على auteur، وبأي اسم مستعار، وبأي لهجة SQL. غيّر اسم عمود في الـ mapping يبقى الاستعلام صالحًا، لأنه لم يتحدث يومًا عن الأعمدة.

الثمن المقابل أن استعلام JPQL سلسلة نصية: المترجم لا يراجعها. خطأ مطبعي في اسم سمة لا يظهر إلا وقت التنفيذ، وإذا كان الاستعلام مسمًّى فإنه يظهر عند بدء تشغيل التطبيق، وهذا أفضل أصلًا. تعالج Criteria API هذه المشكلة تحديدًا ببناء الاستعلام عبر استدعاءات دوال يتحقق منها المترجم وقت التصريف.

هذا الفصل هو أيضًا الذي تتوقف فيه مشكلة الاستعلامات N+1 عن كونها قدرًا محتومًا، لأن الاستعلام، وليس أي مكان آخر، هو الموضع الذي نعلن فيه ما نحتاج إليه. والإسقاطات إلى DTO التي يُختتم بها هذا الدرس هي الجواب الأنظف: فهي لا تجلب إلا الأعمدة المفيدة، وما تُرجعه لا يحتوي على أي وكيل (proxy) قد يُصدر استعلامًا لاحقًا.