स्प्रिंग डेटा जेपीए: फाइलें लाना

अभिवादन, यह स्प्रिंग डेटा जेपीए के बारे में दूसरी पोस्ट है। पहला भाग पूरी तरह से पानी के नीचे की रेक के लिए समर्पित था, साथ ही साथ अनुभवी लोगों के सुझाव भी। इस भाग में हम बात करेंगे कि अपनी आवश्यकताओं के लिए रूपरेखा को कैसे तेज किया जाए। वर्णित सभी उदाहरण यहां उपलब्ध हैं ।

गिनता

चलो शुरू करते हैं, शायद, एक सरल और एक ही समय में सामान्य कार्य के साथ: एक इकाई को लोड करते समय, चुनिंदा रूप से इसकी "बेटी" डाउनलोड करना आवश्यक है। एक साधारण उदाहरण पर विचार करें:

@Entity public class Child { @Id private Long id; @JoinColumn(name = "parent_id") @ManyToOne(fetch = FetchType.LAZY, cascade = CascadeType.ALL) private Parent parent; } @Entity public class Parent { @Id private Long id; } 

हमारे उदाहरण में बाल इकाई आलसी है: हम Child प्राप्त करते समय अनावश्यक डेटा लोड नहीं करना चाहते हैं (और एसक्यूएल क्वेरी में दूसरी तालिका में शामिल हों)। लेकिन हमारे आवेदन में कुछ मामलों में हम यह सुनिश्चित करने के लिए जानते हैं कि हमें बच्चे और उसके माता-पिता दोनों की आवश्यकता होगी। यदि आप इकाई को आलसी छोड़ देते हैं, तो हमें 2 अलग-अलग अनुरोध मिलते हैं। यदि आप FetchType.LAZY को हटाकर तेजी से लोडिंग लागू करते हैं, तो दोनों संस्थाएं हमेशा पहले अनुरोध पर लोड की जाएंगी (और हम ऐसा नहीं चाहते हैं)।

JPQL बॉक्स से एक अच्छा समाधान प्रदान करता है - यह fetch कीवर्ड है:

 public interface ChildRepository extends JpaRepository<Child, Long> { @Query("select c from Child c join fetch c.parent where c.id = :id") Child findByIdFetchParent(@Param("id") Long id); } 

यह अनुरोध सरल और स्पष्ट है, लेकिन इसमें कमियां हैं:

• हमने वास्तव में JpaRepository::findById के तर्क को JpaRepository::findById को स्पष्ट लोडिंग जोड़कर
• @Query उपयोग करके वर्णित प्रत्येक क्वेरी को एप्लिकेशन स्टार्टअप पर @Query है, जिसमें क्वेरी को पार्स करने, तर्कों को जांचने, आदि की आवश्यकता होती है (देखें org.springframework.data.jpa.repository.query.SimpleJpaQuery :: validateQuery )। यह सब काम है जो समय और स्मृति लेता है।
• दर्जनों रिपॉजिटरी और entwined संस्थाओं के साथ एक बड़ी परियोजना में इस तरह के दृष्टिकोण का उपयोग (कभी-कभी एक दर्जन "बेटियों") के साथ एक दहनशील विस्फोट का कारण होगा।

मायने रखता है हमारी सहायता के लिए:

 @Entity @NamedEntityGraphs(value = { @NamedEntityGraph( name = Child.PARENT, attributeNodes = @NamedAttributeNode("parent") ) }) public class Child { public static final String PARENT = "Child[parent]"; @Id private Long id; @JoinColumn(name = "parent_id") @ManyToOne(fetch = FetchType.LAZY, cascade = CascadeType.ALL) private Parent parent; } 

ग्राफ का वर्णन करना आसान है, इसका उपयोग करते समय कठिनाइयां शुरू होती हैं। अपने पेज पर स्प्रिंग डाटा जेपीए इसे इस तरह से करने का सुझाव देता है (जैसा कि हमारे मामले पर लागू होता है)

 public interface GroupRepository extends JpaRepository<GroupInfo, String> { @EntityGraph(value = Child.PARENT) @Query("select c from Child c where c.id = :id") Child findByIdFetchParent(@Param("id") Long id); } 

यहां हम सभी समान समस्याओं को देखते हैं (सिवाय इसके कि लिखित अनुरोध थोड़ा आसान हो गया है)। आप उन्हें ठीक ट्यूनिंग की मदद से एक झटके में समाप्त कर सकते हैं। अपना स्वयं का इंटरफ़ेस बनाएँ, जिसका उपयोग हम बॉक्सिंग JpaRepository बजाय रिपॉजिटरी बनाने के लिए JpaRepository :

 @NoRepositoryBean public interface BaseJpaRepository<T, ID extends Serializable> extends JpaRepository<T, ID> { T findById(ID id, String graphName); } 

अब कार्यान्वयन:

 public class BaseJpaRepositoryImpl<T, ID extends Serializable> extends SimpleJpaRepository<T, ID> implements BaseJpaRepository<T, ID> { private final JpaEntityInformation<T, ?> entityInfo; private final EntityManager entityManager; public BaseJpaRepositoryImpl(JpaEntityInformation<T, ?> ei, EntityManager em) { super(ei, em); this.entityInfo = ei; this.entityManager = em; } @Override public T findById(ID id, String graphName) { Assert.notNull(id, "The given id must not be null!"); //  EntityGraph<?> graph = entityManager.getEntityGraph(graphName); Map<String, Object> hints = singletonMap(QueryHints.HINT_LOADGRAPH, graph); return entityManager.find(getDomainClass(), id, hints); } 

अब स्प्रिंग को हमारे आवेदन के सभी रिपॉजिटरी के आधार के रूप में BaseJpaRepositoryImpl का उपयोग करने के लिए BaseJpaRepositoryImpl करें:

 @EnableJpaRepositories(repositoryBaseClass = BaseJpaRepositoryImpl.class) public class AppConfig { } 

अब हमारी विधि हमारे BaseJpaRepository से विरासत में मिली सभी रिपॉजिटरी से उपलब्ध होगी।

इस दृष्टिकोण में एक दोष है जो बहुत मोटा सुअर डाल सकता है।

 Optional<MyEntity> entity = repository.findById(id, NON_EXISTING_GRAPH); 

आप परीक्षण का उपयोग कर समाधान के स्वास्थ्य की जांच कर सकते हैं:

 @Sql("/ChildRepositoryGraphTest.sql") public class ChildRepositoryGraphTest extends TestBase { private final Long childId = 1L; @Test public void testGraph_expectFieldInitialized() { Child child1 = childRepository.findOne(childId, Child.PARENT); boolean initialized = Hibernate.isInitialized(child1.getParent()); assertTrue(initialized); } @Test public void testGraph_expectFieldNotInitialized() { Child child1 = childRepository .findById(childId) .orElseThrow(NullPointerException::new); boolean initialized = Hibernate.isInitialized(child1.getParent()); assertFalse(initialized); } } 

जब पेड़ बड़े थे

और हम छोटे और अनुभवहीन थे, हमें अक्सर यह कोड देखना पड़ता था:

 public List<DailyRecord> findBetweenDates(Date from, Date to) { StringBuilder query = new StringBuilder("from Record "); if (from != null) { query.append(" where date >=").append(format(from)).append(" "); } if (to != null) { if (from == null) { query.append(" where date <= " + format(to) + " "); } else { query.append(" and date <= " + format(to) + " "); } } return em.createQuery(query.toString(), DailyRecord.class).getResultList(); } 

यह कोड टुकड़ा द्वारा अनुरोध टुकड़ा एकत्र करता है। इस दृष्टिकोण के नुकसान स्पष्ट हैं:

• आपको अपने हाथों से बहुत कुछ करना है
• जहाँ मैनुअल काम है - गलतियाँ हैं
• कोई सिंटैक्स हाइलाइटिंग (रनटाइम के दौरान टाइपो पॉप अप)
• कोड का विस्तार करना और उसे बनाए रखना बहुत मुश्किल है

थोड़ी देर बाद, मानदंड एपीआई दिखाई दिया, जिसने हमें उपरोक्त कोड को थोड़ा निचोड़ने की अनुमति दी:

 public List<DailyRecord> findBetweenDates(Date from, Date to) { Criteria criteria = em .unwrap(Session.class) .createCriteria(DailyRecord.class); if (from != null) { criteria.add(Expression.ge("date", from)); } if (to != null) { criteria.add(Expression.le("date", to)); } return criteria.list(); } 

मानदंड का उपयोग करने के कई फायदे हैं:

• "तिथि" जैसे "वायर्ड" मूल्यों के बजाय एक मेटामॉडल का उपयोग करने की क्षमता
• अनुरोध के निर्माण में कुछ त्रुटियां संकलन त्रुटियां हैं, अर्थात्, लिखते समय उन्हें पहले से ही पता चल जाता है
• कोड बेवकूफ चिपकाने वाले तार की तुलना में छोटा और अधिक समझदार है

इसके नुकसान भी हैं:

• कोड समझने के लिए पर्याप्त जटिल है
• इस तरह के प्रश्नों को लिखने के बारे में जानने के लिए आपको अपना हाथ भरने की आवश्यकता है (मुझे याद है कि जब मुझे पहली बार इस तरह के प्रश्नों में त्रुटि सुधार से निपटना पड़ा था, तो कभी-कभी 100-150 लाइनों से युक्त होता है, ब्रांचिंग के साथ, आदि)
• एक जटिल क्वेरी बल्कि बोझिल है (50 लाइनें सीमा से बहुत दूर हैं)

मैं इसे आसानी से और आनंद के साथ विकसित करना चाहता हूं, इसलिए मैं इन दोनों तरीकों की तरह नहीं हूं।

आइए हम अपने द्वारा पहले से जाँची गई इकाई को देखें:

 @Entity public class Child { @Id private Long id; @JoinColumn(name = "parent_id") @ManyToOne(fetch = FetchType.LAZY, cascade = CascadeType.ALL) private Parent parent; //... @OneToMany(mappedBy = "owner", cascade = CascadeType.ALL) @LazyCollection(value = LazyCollectionOption.EXTRA) private List<Toy> toys = new ArrayList<>(); } 

मैं अलग-अलग मोड (और उनके संयोजन) में एक इकाई को लोड करने में सक्षम होना चाहूंगा:

• लोड (या नहीं) जनक
• लोड (या नहीं) खिलौने
• बच्चों को उम्र के अनुसार क्रमबद्ध करें

यदि आप इस समस्या को हल करते हैं, अर्थात्, बहुत सारे प्रश्नों को लिखकर जो चयनित लोडिंग मोड के अनुरूप हैं, तो बहुत जल्दी यह एक दहनशील विस्फोट की ओर ले जाएगा:

  @Query("select c from Child c join fetch c.parent order by c.age") List<Child> findWithParentOrderByAge(); @Query("select c from Child c join fetch c.toys order by c.age") List<Child> findWithToysOrderByAge(); @Query("select c from Child c join fetch c.parent join fetch c.toys") List<Child> findWithParentAndToys(); //... 

इस समस्या को हल करने का एक सरल और सुरुचिपूर्ण तरीका है: SQL / HQL और टेम्पलेट इंजन का एक संयोजन। "फ्रीमार्कर" का उपयोग मेरी परियोजनाओं पर किया गया था, हालांकि अन्य समाधानों का उपयोग किया जा सकता है ("टिमलिफ़", "मस्टैश", आदि)।

चलिए बनाना शुरू करते हैं। सबसे पहले, हमें एक फ़ाइल में क्वेरी का वर्णन करने की आवश्यकता है जो *.hql.ftl या *.sql.ftl (यदि "शुद्ध" एसक्यूएल का उपयोग कर) प्राप्त करता है:

 #* @vtlvariable name="fetchParent" type="java.lang.Boolean" *# #* @vtlvariable name="fetchToys" type="java.lang.Boolean" *# #* @vtlvariable name="orderByAge" type="java.lang.Boolean" *# select child from Child child #if($fetchParent) left join fetch child.parent #end #if($fetchToys) left join fetch child.toys #end #if($orderByAge) order by child.age #end 

अब आपको एक हैंडलर की जरूरत है:

 @Component @RequiredArgsConstructor public class TemplateParser { private final Configuration configuration; @SneakyThrows public String prepareQuery(String templateName, Map<String, Object> params){ Template template = configuration.getTemplate(templateName); return FreeMarkerTemplateUtils.processTemplateIntoString(template, params); } } 

कुछ भी जटिल नहीं है। भंडार के लिए हो रही है। जाहिर है, JpaRepository को प्राप्त करने वाला इंटरफ़ेस हमें सूट नहीं करता है। इसके बजाय, हम अपने स्वयं के रिपोजिटरी बनाने के अवसर का उपयोग करेंगे:

 public interface ChildRepositoryCustom { List<Child> findAll(boolean fetchParent, boolean fetchToys, boolean order); } @RequiredArgsConstructor public class ChildRepositoryImpl extends BaseDao implements ChildRepositoryCustom { private final TemplateParser templateParser; @Override public List<Child> findAll(boolean fetchParent, boolean fetchToys, boolean order) { Map<String, Object> params = new HashMap<>(); params.put("fetchParent", fetchParent); params.put("fetchToys", fetchToys); params.put("orderByAge", orderByAge); String query = templateParser.prepareQuery(BASE_CHILD_TEMPLATE.name, params); return em.createQuery(query, Child.class).getResultList(); } @RequiredArgsConstructor enum RepositoryTemplates { BASE_CHILD_TEMPLATE("BaseChildTemplate.hql.ftl"); public final String name; } } 

findUsingTemplate से findUsingTemplate विधि को सुलभ बनाने के लिए ChildRepository आपको यह करने की आवश्यकता है:

 public interface ChildRepository extends BaseJpaRepository<Child, Long>, ChildRepositoryCustom { //... } 

अब इस दृष्टिकोण का उपयोग करके आप अधिक जटिल समस्याओं को हल कर सकते हैं। मान लीजिए कि हमें उपयोगकर्ता-चयनित विशेषताओं के आधार पर चयन करने की आवश्यकता है। दूसरे शब्दों में, यदि उपयोगकर्ता ने "से" और "से" तारीखों को निर्दिष्ट नहीं किया है, तो कोई समय फ़िल्टर नहीं होगा। यदि केवल दिनांक "से" या केवल दिनांक "से" निर्दिष्ट है, तो फ़िल्टरिंग एक तरफ़ा होगी। यदि दोनों तिथियां निर्दिष्ट की जाती हैं, तो केवल निर्दिष्ट तिथियों के बीच रिकॉर्ड चयन में आएगा:

 @Getter @RequiredArgsConstructor public class RequestDto { private final LocalDate from; private final LocalDate to; public boolean hasDateFrom() { return from != null; } public boolean hasDateTo() { return to != null; } } @Override public List<Child> findAll(ChildRequest request) { Map<String, Object> params = singletonMap("request", request); String query = templateParser.prepareQuery(TEMPLATE.name, params); return em.createQuery(query, Child.class).getResultList(); } 

अब टेम्पलेट:

 <#-- @ftlvariable name="request" type="...RequestDto" --> select child from Child child <#if request.hasDateFrom() && request.hasDateTo()> where child.birthDate >= :dateFrom and child.birthDate <= :dateTo <#elseif request.hasDateFrom()> where child.birthDate >= :dateFrom <#elseif request.hasDateTo()> where child.birthDate <= :dateTo </#if> 

ओरेकल और एनवीएल

सार पर विचार करें:

 @Entity public class DailyRecord { @Id private Long id; @Column private String currency; @Column(name = "record_rate") private BigDecimal rate; @Column(name = "fixed_rate") private BigDecimal fxRate; @Setter(value = AccessLevel.PRIVATE) @Formula("select avg(r.record_rate) from daily_record r where r.currency = currency") private BigDecimal avgRate; } 

इस इकाई का उपयोग क्वेरी में किया जाता है (DBMS, जैसा कि हम याद करते हैं, हमारे पास Oracle है):

 @Query("select nvl(record.fxRate, record.avgRate) " + " from DailyRecord record " + "where record.currency = :currency") BigDecimal findRateByCurrency(@Param("currency") String currency); 

यह एक कामकाजी, वैध अनुरोध है। लेकिन इसके साथ एक छोटी समस्या है, जिसे SQL विशेषज्ञ शायद इंगित करेंगे। तथ्य यह है कि ओरेकल में nvl आलसी नहीं है। दूसरे शब्दों में, जब हम findRateByCurrency विधि को कॉल करते हैं, तो findRateByCurrency लॉग findRateByCurrency होगा

 select nvl( dr.fixed_rate, select avg(r.record_rate) from daily_record r where r.currency = dr.currency ) from daily_record dr where dr.currency = ? 

भले ही dr.fixed_rate मान मौजूद हो, लेकिन DBMS अभी भी nvl में दूसरी अभिव्यक्ति द्वारा लौटाए गए मूल्य की गणना करता है, जो हमारे मामले में

 select avg(r.record_rate) from daily_record r where r.currency = dr.currency) 

पाठक शायद पहले से ही जानता है कि अनुरोध के अनावश्यक भार को कैसे चकमा देना है: बेशक, यह कीवर्ड nvl , जो अपने आलस्य के साथ nvl अनुकूलता की तुलना करता है, साथ ही 2 से अधिक अभिव्यक्तियों को स्वीकार करने की क्षमता है। चलो हमारे अनुरोध को सही करें:

 @Query("select coalesce(record.fxRate, record.avgRate) " + " from DailyRecord record " + "where record.currency = :currency") BigDecimal findRateByCurrency(@Param("currency") String currency); 

और फिर, जैसा कि वे कहते हैं, अचानक:

 select nvl(dr.fixed_rate, select avg(r.record_rate) from daily_record r where r.currency = dr.currency) from daily_record dr where dr.currency = ? 

अनुरोध वही रहा। ऐसा इसलिए है क्योंकि बॉक्स से दैवीय बोली एक nvl श्रृंखला में तब्दील हो nvl है।

इसे चकमा देने के लिए आपको अपनी बोली बनाने और एप्लिकेशन में उपयोग करने की आवश्यकता है:

 public class CustomOracleDialect extends Oracle12cDialect { public CustomOracleDialect() { super(); registerFunction("coalesce", new StandardSQLFunction("coalesce")); } } 

हां, यह बहुत आसान है। अब हम बनाई गई बोली को एप्लिकेशन पर बाँधते हैं:

 spring: jpa: database-platform: com.luxoft.logeek.config.CustomOracleDialect 

 spring: jpa: properties: hibernate.dialect: com.luxoft.logeek.config.CustomOracleDialect 

अनुरोध को बार-बार निष्पादित करने से प्रतिष्ठित कोलेसस्क प्राप्त होता है:

 select coalesce(dr.fixed_rate, select avg(r.record_rate) from daily_record r where r.currency = dr.currency) from daily_record dr where dr.currency = ? 

ओरेकल और पेज अनुरोध

सामान्य तौर पर, बोली के पूरा होने से क्वेरी हेरफेर के लिए समृद्ध अवसर मिलते हैं। अक्सर एक एप्लिकेशन और एक वेब चेहरे को विकसित करते समय, डेटा के पेज-वार अपलोड करने का कार्य सामना करना पड़ता है। दूसरे शब्दों में, डेटाबेस में हमारे कई सौ हजार रिकॉर्ड हैं, लेकिन वे प्रति पृष्ठ 10/50/100 रिकॉर्ड के पैक में प्रदर्शित किए जाते हैं। बॉक्स से स्प्रिंग डेट डेवलपर को समान कार्यक्षमता प्रदान करती है:

 @Query("select new com.luxoft.logeek.data.BriefChildData(" + "c.id, " + "c.age " + ") from Child c " + " join c.parent p " + "where p.name = ''") Page<BriefChildData> browse(Pageable pageable); 

इस दृष्टिकोण में एक महत्वपूर्ण कमी है, अर्थात्, दो प्रश्नों का निष्पादन, जिनमें से पहला डेटा प्राप्त करता है, और दूसरा डेटाबेस में उनकी कुल संख्या निर्धारित करता है ( Page ऑब्जेक्ट में डेटा की कुल मात्रा प्रदर्शित करने के लिए यह आवश्यक है)। हमारे मामले में, इस विधि के लिए एक कॉल निम्नलिखित अनुरोध देता है (p6spy का उपयोग करके लॉगिंग):

 select * from ( select c.id, c.age from child c inner join parent p on c.parent_id = p.id where p.name = '' ) where rownum <= 3; select count(c.id) from child c inner join parent p on c.parent_id = p.id where p.name = '' 

यदि क्वेरी भारी है (कई तालिकाओं को एक गैर-अनुक्रमिक स्तंभ से जोड़ा जाता है, तो बस बहुत सारे जोड़, एक कठिन चयन स्थिति, आदि), तो यह एक समस्या बन सकती है। लेकिन चूंकि हमारे पास ओरेकल है, तो आप एक अनुरोध के साथ प्राप्त कर सकते हैं पंक्तिबद्ध छद्म-स्तंभ का उपयोग करना।

ऐसा करने के लिए, हमें अपनी बोली समाप्त करने की आवश्यकता है, और सभी रिकॉर्डों को गिनने के लिए उपयोग किए जाने वाले फ़ंक्शन का वर्णन करें:

 public class CustomOracleDialect extends Oracle12cDialect { public CustomOracleDialect() { super(); registerFunction("coalesce", new StandardSQLFunction("coalesce")); registerFunction("total_count", new TotalCountFunc()); } } public class TotalCountFunc implements SQLFunction { @Override public boolean hasArguments() { return true; } @Override public boolean hasParenthesesIfNoArguments() { return true; } @Override public Type getReturnType(Type type, Mapping mapping) { return StandardBasicTypes.LONG; } @Override public String render(Type type, List arguments, SessionFactoryImplementor factory) { if (arguments.size() != 1) { throw new IllegalArgumentException("Only 1 argument acceptable"); } return " count(" + arguments.get(0) + ") over () "; } } 

अब एक नई क्वेरी ( ChildRepositoryImpl वर्ग में) ChildRepositoryImpl :

 @Override public Page<BriefChildData> browseWithTotalCount(Pageable pageable) { String query = "select " + " c.id as id," + " c.age as age, " + " total_count(c.id) as totalCount" + " from Child c " + "join c.parent p " + "where p.name = ''"; List<BriefChildData> list = em.unwrap(Session.class) .createQuery(query) .setFirstResult((int) pageable.getOffset()) .setMaxResults(pageable.getPageSize()) .setResultTransformer(Transformers.aliasToBean(BriefChildData.class)) .getResultList(); if (list.isEmpty()) { return new PageImpl(Collections.emptyList()); } long totalCount = list.get(0).getTotalCount(); return new PageImpl<>(list, pageable, totalCount); } 

इस कोड को कॉल करते समय, एक अनुरोध निष्पादित किया जाएगा

 select * from (select c.id, c.age, count(c.id) over () -- <----- from child c inner join parent p on c.parent_id = p.id where p.name = '') where rownum <= 3 

अभिव्यक्ति count(c.id) over () का उपयोग करके count(c.id) over () आप डेटा की कुल राशि प्राप्त कर सकते हैं और इसे PageImpl कंस्ट्रक्टर को पास करने के लिए डेटा वर्ग से प्राप्त कर सकते हैं। डेटा श्रेणी में किसी अन्य फ़ील्ड को शामिल किए बिना इसे अधिक सुरुचिपूर्ण ढंग से करने का एक तरीका है, इसे होमवर्क पर विचार करें :) आप ProjectionVsDataTest परीक्षण का उपयोग करके समाधान का परीक्षण कर सकते हैं।

अनुकूलन के नुकसान

हमारे पास ओरेकल और स्प्रिंग डेट के साथ एक अच्छा प्रोजेक्ट है। हमारा कार्य इस तरह के कोड के प्रदर्शन में सुधार करना है:

 List<Long> ids = getIds(); ids.stream() .map(repository::findById) .filter(Optional::isPresent) .map(Optional::get) .forEach(this::sendToSchool); 

नुकसान सतह पर है: डेटाबेस प्रश्नों की संख्या अद्वितीय कुंजियों की संख्या के बराबर है। इस कठिनाई पर काबू पाने की एक ज्ञात विधि है:

 List<Long> ids = getIds(); repository .findAllById(ids) .forEach(this::sendToSchool); 

एकाधिक नमूने का लाभ स्पष्ट है: यदि पहले हमारे पास फॉर्म के कई समान प्रश्न थे

 select p.* from Pupil p where p.id = 1 select p.* from Pupil p where p.id = 2 select p.* from Pupil p where p.id = 3 

तब अब वे एक के लिए ढह गए हैं

 select p.* from Pupil p where p.id in (1, 2, 3, ... ) 

यह आसान हो गया है और अच्छा हो गया है। प्रोजेक्ट बढ़ता है, विकसित होता है, डेटा बढ़ता है और एक बार अपरिहार्य आता है:

 ERROR - ORA-01795: maximum number of expressions in a list is 1000 

हमें फिर से एक रास्ता तलाशने की जरूरत है (पुराने संस्करण पर वापस नहीं)। चूंकि ओरेकल उसे 1000 से अधिक कुंजियों को खिलाने की अनुमति नहीं देता है, तो आप पूरे डेटा को 1000 से अधिक नहीं के बराबर शेयरों में विभाजित कर सकते हैं और कई प्रश्नों की संख्या निष्पादित कर सकते हैं:

 List<List<Long>> idChunks = cgccLists.partition(ids, 1000); //* idChunks.forEach(idChunk -> repository.findAllById(idChunk).forEach(this::sendToSchool) ); //* cgccLists = com.google.common.collect.Lists 

यह विधि काम करती है, लेकिन यह थोड़ा बदबू आ रही है (यह है?): यदि आप अन्य जगहों पर ऐसी कठिनाइयों का सामना करते हैं तो आपको उसी बगीचे में बाड़ लगाना होगा। चलिए BaseJpaRepositoryImpl को BaseJpaRepositoryImpl करके समस्या को अधिक सुरुचिपूर्ण ढंग से हल करने का प्रयास करते हैं। ऐसा करने का सबसे आसान तरीका यह है कि उपरोक्त तर्क को भीतर से स्थानांतरित करना, इसे उपयोगकर्ता से छिपाएं:

 @Override public List<T> findAllById(Iterable<ID> ids) { Assert.notNull(ids, "The given Iterable of Id's must not be null!"); Set<ID> idsCopy = Sets.newHashSet(ids); if (idsCopy.size() <= OracleConstants.MAX_IN_COUNT) { return super.findAllById(ids); } return findAll(idsCopy); } private List<T> findAll(Collection<ID> ids) { List<List<ID>> idChunks = Lists.partition(new ArrayList<>(ids), 1000); return idChunks .stream() .map(this::findAllById) .flatMap(List::stream) .collect(Collectors.toList()); } 

यह बेहतर हो गया: सबसे पहले, हमने बुनियादी ढांचे की परतों से काम करने वाले कोड को साफ किया, और दूसरी बात, हमने अपने समाधान के दायरे का विस्तार सभी परियोजना रिपॉजिटरी में किया जो BaseJpaRepository विस्तार BaseJpaRepository । इसके नुकसान भी हैं। मुख्य एक के बजाय कई अनुरोध हैं, और यह भी (मुख्य एक से उपजा है) - कुंजी को फ़िल्टर करने की आवश्यकता है, क्योंकि यदि ऐसा नहीं किया जाता है, तो एक ही कुंजी अलग-अलग idChunks में दिखाई दे सकती है। यह, बदले में, इसका मतलब है कि एक ही इकाई को दो बार सूची में शामिल किया जाएगा, और, तदनुसार, दो बार संसाधित किया जाएगा। हमें इसकी आवश्यकता नहीं है, इसलिए यहां एक और, अधिक परिष्कृत समाधान है:

 @Override public List<T> findAllById(Iterable<ID> ids) { Assert.notNull(ids, "The given Iterable of Id's must not be null!"); ArrayList<ID> idsCopy = Lists.newArrayList(ids); if (idsCopy.size() <= OracleConstants.MAX_IN_COUNT) { return super.findAllById(ids); } return findAll(idsCopy); } private List<T> findAll(ArrayList<ID> ids) { CriteriaBuilder cb = entityManager.getCriteriaBuilder(); CriteriaQuery<T> query = cb.createQuery(getDomainClass()); Root<T> from = query.from(getDomainClass()); Predicate predicate = toPredicate(cb, ids, from); query = query.select(from).where(predicate); return entityManager.createQuery(query).getResultList(); } private Predicate toPredicate(CriteriaBuilder cb, ArrayList<ID> ids, Root<T> root) { List<List<ID>> chunks = Lists.partition(ids, OracleConstants.MAX_IN_COUNT); SingularAttribute<? super T, ?> id = entityInfo.getIdAttribute(); Predicate[] predicates = chunks.stream() .map(chunk -> root.get(id).in(chunk)) .toArray(Predicate[]::new); return cb.or(predicates); } 

यह क्राइटेरिया एपीआई का उपयोग करता है, जिससे फॉर्म की एक अंतिम क्वेरी बनाना संभव हो जाता है

 select p.* from Pupil p where p.id in (1, 2, ... , 1000) or p.id in (1001, ... , 2000) or p.id in (2001, ... , 3000) 

एक सूक्ष्मता है: एक समान अनुरोध बोझिल परिस्थितियों के कारण सामान्य से अधिक समय तक निष्पादित किया जा सकता है, इसलिए पहली विधि (कभी-कभी) बेहतर हो सकती है।

यह सब, मुझे आशा है कि उदाहरण आपके लिए उपयोगी थे और रोजमर्रा के विकास में उपयोगी थे। टिप्पणियाँ और परिवर्धन का स्वागत है।