हाइबरनेट के साथ स्प्रिंग डेटा जेपीए का उपयोग करने वाले एक वेब एप्लिकेशन में, हम web pagination कार्यक्षमता का उपयोग इकाइयों की विभिन्न सूचियों में पेजिंग और सॉर्टिंग क्षमताओं को प्रदान करने के लिए करते हैं।स्प्रिंग डेटा जेपीए अमान्य पेज.sort पैरामीटर्स
@Controller
public class MyEntityController {
@RequestMapping(method = RequestMethod.GET)
public ModelAndView list(Pageable pageable) { ... }
}
@Configuration
public class MyWebMvcConfig extends WebMvcConfigurationSupport {
@Override
public void addArgumentResolvers(List<HandlerMethodArgumentResolver> argumentResolvers) {
super.addArgumentResolvers(argumentResolvers);
argumentResolvers.add(new PageableArgumentResolver());
}
}
public interface MyEntityRepository extends PagingAndSortingRepository<MyEntity, String> {
Page<MyEntity> findByPropertyX(String propertyX, Pageable pagable);
}
यह अनुमति देता है के लिए इकाई गुण गाया html में के रूप में विशेष प्रकार request parameters, जहां page.sort मूल्य वास्तव में जिस पर सॉर्ट करने के लिए इकाई में एक संपत्ति से मेल खाता है परिभाषित किया जाना है।
<table>
<thead>
<tr>
<th><a href="?page.sort=propertyX&page.sort.dir=asc">Property X</a></th>
<th><a href="?page.sort=propertyY&page.sort.dir=asc">Property Y</a></th>
</tr>
</thead>
<tbody>...</tbody>
</table>
इस तरह के रूप में एक परिणामी URL का उत्पादन:
http://host/context-root/entities/?page.sort=propertyX&page.sort.dir=asc
समस्या उन URL अमान्य page.sort गुणों का उपयोग करने के लिए संशोधित कर सकते हैं वह यह है कि है कि या तो संदर्भ न के बराबर स्तंभ/संपत्ति के नाम, या बुरा, जो अवैध जेपीए क्वेरी वर्णों का उपयोग करता है जिसके परिणामस्वरूप अमान्य वाक्यविन्यास होता है।
उदाहरण के लिए, यदि URL "noSuchProperty" पर सॉर्ट करने के लिए संशोधित किया गया है:
http://host/context-root/entities/?page.sort=noSuchProperty&page.sort.dir=asc
लेकिन इस संपत्ति मौजूद नहीं है, निम्न अपवाद फेंक दिया जाएगा:
java.lang.IllegalArgumentException: No property noSuchProperty found for type class com.my.company.MyEntity
at org.springframework.data.repository.query.parser.Property.<init>(Property.java:76)
. . .
at org.springframework.data.repository.query.parser.AbstractQueryCreator.createQuery(AbstractQueryCreator.java:86)
. . .
at $Proxy68.findByPropertyX(Unknown Source)
at com.my.company.MyEntityRepository.findByPropertyX(MyEntityRepository.java:17
इसी तरह, यदि यूआरएल को अमान्य क्वेरी सिंटैक्स कैरेक्टर में संशोधित किया गया है, जैसे कि "":
http://host/context-root/entities/?page.sort=%22&page.sort.dir=asc
निम्न त्रुटि या हो जाएगा:
java.lang.StackOverflowError
java.util.regex.Pattern$GroupTail.match(Pattern.java:4227)
. . .
org.springframework.data.repository.query.parser.Property.create(Property.java:326)
org.springframework.data.repository.query.parser.Property.create(Property.java:326)
org.springframework.data.repository.query.parser.Property.create(Property.java:326)
org.springframework.data.repository.query.parser.Property.create(Property.java:326)
(वहाँ भी है, जिसमें परिणाम अपवाद की एक तिहाई स्वाद है एक org.hibernate.QueryException जब @Query स्पष्ट भंडार पद्धति पर परिभाषित किया गया है।)
स्प्रिंग डाटा जेपीए के विवरण दूर सार इन पैरामीटरों को सॉर्टिंग, पेजिंग और हैंडलिंग; हालांकि, यह इन परिदृश्यों को गहन रूप से संभालने में प्रतीत नहीं होता है (यानी जहां एक अमान्य सॉर्ट पैरामीटर निर्दिष्ट है)।
हम कुछ अतिरिक्त कस्टम तर्क में जोड़ सकते हैं ताकि यह सत्यापित किया जा सके कि प्रकार की संपत्ति वास्तव में इकाई पर मौजूद है; हालांकि, मैं सोच रहा हूं कि ऐसा करने के लिए एक क्लीनर अधिक केंद्रीकृत दृष्टिकोण है कि हम स्प्रिंग डेटा जेपीए अबास्ट्रक्शन के लाभ और सादगी को खोना नहीं चाहते हैं। हम कई अलग-अलग इकाइयों के साथ अपने ऐप में इस सॉर्टिंग क्षमता का उपयोग करते हैं, इसलिए आदर्श रूप से, हम अनुरोध किए गए प्रत्येक इकाई पृष्ठ के लिए सॉर्ट गुणों को स्पष्ट रूप से परिभाषित या जांचने के बजाय, एक सामान्य दृष्टिकोण चाहते हैं।
विशेष रूप से, हम वास्तव में PageableArgumentResolver का विस्तार है कि हमारे नियंत्रक (सादगी के लिए कोड उदाहरण में सचित्र नहीं) में प्रदान की जाती है एक एनोटेट तरह डिफ़ॉल्ट मान स्वीकार करने के लिए, तो हम सिर्फ इस डिफ़ॉल्ट सॉर्ट क्रम पर वापस आने के लिए करना चाहते हैं, या अपवाद फेंकने के बजाए, इकाई के लिए सिर्फ डिफ़ॉल्ट सॉर्टिंग ऑर्डर।
कुछ विचार और प्रयास .. मैं क्वेरी निर्माण को रोकने और सॉर्ट पैरामीटर प्राप्त करने के लिए QueryCreationListener का उपयोग कर सकता हूं; हालांकि, मैं वास्तव में उस बिंदु पर क्वेरी को संशोधित नहीं कर सकता। या, मैं पैरामीटर पैरामीटर को पकड़ने के लिए कस्टम PageableArgumentResolver (हम पहले से ही ऐसा कर रहे हैं) का विस्तार और उपयोग कर सकते हैं; हालांकि, मेरे पास उस बिंदु पर इकाई तक पहुंच नहीं है, न ही यह निर्धारित करने की क्षमता है कि इकाई के पास उस नाम से वास्तव में संपत्ति है या नहीं।हम समर्थित गुणों को स्पष्ट रूप से घोषित कर सकते हैं; हालांकि, फिर से, यह केंद्र के विचार को हरा देता है और संस्थाओं के विशिष्ट या घोषित ज्ञान की आवश्यकता के बिना स्वचालित रूप से इस परिदृश्य को संभाला जाता है।
क्या कोई अन्य प्रकार का इंटरसेप्टर या इसी तरह का निर्माण है जिसका उपयोग मैं पेजेबल सॉर्ट पैरामीटर को केंद्रीय रूप से मान्य करने के लिए उपयोग कर सकता हूं और क्वेरी को आमंत्रित करने से पहले आवश्यक हो सकता हूं? या क्या कोई प्रकार का कॉन्फ़िगरेशन या तरीका है कि स्प्रिंग स्वचालित रूप से इस परिदृश्य को संभाल सकता है जैसे कि यह अजीब तरह से अमान्य सॉर्ट पैरा को संभालता है?