स्प्रिंग डेटा जेपीए: क्या अच्छा है और क्या बुरा

बच्चा बेटा अपने पिता के पास आया
और बच्चे से पूछा
- अच्छा क्या है
और क्या बुरा है

व्लादिमीर मायाकोवस्की

यह लेख स्प्रिंग डेटा जेपीए के बारे में है, अर्थात् पानी के नीचे की रेक में जो मुझे अपने रास्ते पर मिले थे, और निश्चित रूप से प्रदर्शन के बारे में थोड़ा।

लेख में वर्णित उदाहरणों को संदर्भ द्वारा सुलभ, परीक्षण वातावरण में चलाया जा सकता है।

 public interface CrudRepository<T, ID> { T findOne(ID id); List<T> findAll(Iterable<ID> ids); } 

 public interface CrudRepository<T, ID> { Optional<T> findById(ID id); List<T> findAllById(Iterable<ID> ids); } 

तो चलिए शुरू करते हैं।

t से चुनें। जहां t.id से (...)

सबसे सामान्य प्रश्नों में से एक फॉर्म की एक क्वेरी है "सभी रिकॉर्ड का चयन करें जिसके लिए कुंजी प्रेषित सेट में आती है"। मुझे यकीन है कि आप लगभग सभी ने कुछ लिखा या देखा होगा

 @Query("select ba from BankAccount ba where ba.user.id in :ids") List<BankAccount> findByUserIds(@Param("ids") List<Long> ids); @Query("select ba from BankAccount ba where ba.user.id in :ids") List<BankAccount> findByUserIds(@Param("ids") Set<Long> ids); 

ये काम कर रहे हैं, उपयुक्त अनुरोध हैं, कोई पकड़ या प्रदर्शन समस्या नहीं है, लेकिन एक छोटी सी, पूरी तरह से असंगत कमी है।

 public List<BankAccount> findByUserId(List<Long> userIds) { Set<Long> ids = new HashSet<>(userIds); return repository.findByUserIds(ids); } // public List<BankAccount> findByUserIds(Set<Long> userIds) { List<Long> ids = new ArrayList<>(userIds); return repository.findByUserIds(ids); } 

 @Query("select ba from BankAccount ba where ba.user.id in :ids") List<BankAccount> findByUserIds(@Param("ids") Iterable<Long> ids); 

 public interface BankAccountRepositoryCustom { boolean anyMoneyAvailable(Collection<Long> accountIds); } public class BankAccountRepositoryImpl { @Override public boolean anyMoneyAvailable(Collection<Long> accountIds) { if (ids.isEmpty()) return false; //... } } 

अतिरिक्त कोड: गैर-डुप्लिकेट कुंजी

अंतिम खंड की निरंतरता में, मैं एक आम गलत धारणा पर ध्यान आकर्षित करना चाहता हूं:

 @Query("select ba from BankAccount ba where ba.user.id in :ids") List<BankAccount> findByUserIds(@Param("ids") Set<Long> ids); 

एक ही त्रुटि के अन्य अभिव्यक्तियाँ:

 Set<Long> ids = new HashSet<>(notUniqueIds); List<BankAccount> accounts = repository.findByUserIds(ids); List<Long> ids = ts.stream().map(T::id).distinct().collect(toList()); List<BankAccount> accounts = repository.findByUserIds(ids); Set<Long> ids = ts.stream().map(T::id).collect(toSet()); List<BankAccount> accounts = repository.findByUserIds(ids); 

पहली नज़र में, कुछ भी असामान्य नहीं है, है ना?

 select b.* from BankAccount b where b.user_id in (?, ?, ?, ?, ?, …) 

 @Query("select ba from BankAccount ba where ba.user.id in :ids") List<BankAccount> findByUserIds(@Param("ids") Iterable<Long> ids); 

Samopis

इस कोड पर एक नज़र डालें और यहां तीन खामियों और एक संभावित त्रुटि का पता लगाएं:

 @Query("from User u where u.id in :ids") List<User> findAll(@Param("ids") Iterable<Long> ids); 

हैरी पॉटर और कंपाउंड की

दो उदाहरणों पर एक नज़र डालें और अपना पसंदीदा चुनें:

विधि संख्या बार

 @Embeddable public class CompositeKey implements Serializable { Long key1; Long key2; } @Entity public class CompositeKeyEntity { @EmbeddedId CompositeKey key; } 

विधि संख्या दो

 @Embeddable public class CompositeKey implements Serializable { Long key1; Long key2; } @Entity @IdClass(value = CompositeKey.class) public class CompositeKeyEntity { @Id Long key1; @Id Long key2; } 

पहली नज़र में, कोई अंतर नहीं है। अब पहली विधि का प्रयास करें और एक सरल परीक्षण चलाएं:

 //case for @EmbeddedId @Test public void findAll() { int size = entityWithCompositeKeyRepository.findAllById(compositeKeys).size(); assertEquals(size, 5); } 

क्वेरी लॉग में (आप इसे सही रखें;) हम इसे देखेंगे:

 select e.key1, e.key2 from CompositeKeyEntity e where e.key1 = ? and e.key2 = ? or e.key1 = ? and e.key2 = ? or e.key1 = ? and e.key2 = ? or e.key1 = ? and e.key2 = ? or e.key1 = ? and e.key2 = ? 

अब दूसरा उदाहरण

 //case for @Id @Id @Test public void _findAll() { int size = anotherEntityWithCompositeKeyRepository.findAllById(compositeKeys).size(); assertEquals(size, 5); } 

क्वेरी लॉग अलग दिखता है:

 select e.key1, e.key2 from CompositeKeyEntity e where e.key1=? and e.key2=? select e.key1, e.key2 from CompositeKeyEntity e where e.key1=? and e.key2=? select e.key1, e.key2 from CompositeKeyEntity e where e.key1=? and e.key2=? select e.key1, e.key2 from CompositeKeyEntity e where e.key1=? and e.key2=? select e.key1, e.key2 from CompositeKeyEntity e where e.key1=? and e.key2=? 

यह पूरा अंतर है: पहले मामले में हमें हमेशा 1 अनुरोध प्राप्त होता है, दूसरे में - n अनुरोध।
इस व्यवहार का कारण SimpleJpaRepository::findAllById : SimpleJpaRepository::findAllById :

 // ... if (entityInfo.hasCompositeId()) { List<T> results = new ArrayList<>(); for (ID id : ids) { findById(id).ifPresent(results::add); } return results; } // ... 

अनुरोधों की संख्या कितनी महत्वपूर्ण है, इसके आधार पर यह निर्धारित करना कि आपके लिए कौन सी विधि सर्वोत्तम है।

अतिरिक्त CrudRepository :: सहेजें

अक्सर कोड में इस तरह के एक एंटीपैटर्न होता है:

 @Transactional public BankAccount updateRate(Long id, BigDecimal rate) { BankAccount account = repo.findById(id).orElseThrow(NPE::new); account.setRate(rate); return repo.save(account); } 

पाठक हैरान है: एंटीपैटर्न कहां है? यह कोड बहुत तार्किक लगता है: हमें इकाई - अपडेट - सेव मिलती है। सेंट पीटर्सबर्ग के सबसे अच्छे घरों में सब कुछ पसंद है। मैं यह कहने की हिम्मत करता हूं कि CrudRepository::save को कॉल CrudRepository::save यहां बहुत ही अच्छा है।

पहला: updateRate विधि ट्रांजेक्शनल है, इसलिए, प्रबंधित निकाय में सभी परिवर्तन हाइबरनेट द्वारा ट्रैक किए जाते हैं और एक अनुरोध में बदल जाते हैं जब Session::flush निष्पादित होता है, जो इस कोड में तब होता है जब विधि समाप्त होती है।

दूसरी बात, CrudRepository::save विधि पर एक नज़र डालें। जैसा कि आप जानते हैं, सभी रिपॉजिटरी SimpleJpaRepository रिपॉजिटरी पर आधारित हैं। यहाँ CrudRepository::save का कार्यान्वयन CrudRepository::save :

 @Transactional public <S extends T> S save(S entity) { if (entityInformation.isNew(entity)) { em.persist(entity); return entity; } else { return em.merge(entity); } } 

एक सूक्ष्मता है जो हर किसी को याद नहीं है: हाइबरनेट घटनाओं के माध्यम से काम करता है। दूसरे शब्दों में, प्रत्येक उपयोगकर्ता कार्रवाई एक ऐसी घटना उत्पन्न करती है जो कतारबद्ध और उसी कतार में अन्य घटनाओं को ध्यान में रखते हुए संसाधित होती है। इस स्थिति में, EntityManager::merge लिए एक कॉल EntityManager::merge एक MergeEvent उत्पन्न करता है, जिसे DefaultMergeEventListener::onMerge में डिफ़ॉल्ट रूप से संसाधित किया जाता है। इसमें इकाई-तर्क के प्रत्येक राज्य के लिए काफी शाखित, लेकिन सरल तर्क शामिल हैं। हमारे मामले में, इकाई को ट्रांसेक्शनल विधि के अंदर भंडार से प्राप्त किया जाता है और PERSISTENT राज्य में होता है (यानी, अनिवार्य रूप से ढांचे द्वारा नियंत्रित):

 protected void entityIsPersistent(MergeEvent event, Map copyCache) { LOG.trace("Ignoring persistent instance"); Object entity = event.getEntity(); EventSource source = event.getSession(); EntityPersister persister = source.getEntityPersister(event.getEntityName(), entity); ((MergeContext)copyCache).put(entity, entity, true); this.cascadeOnMerge(source, persister, entity, copyCache); //<---- this.copyValues(persister, entity, entity, source, copyCache); //<---- event.setResult(entity); } 

शैतान विवरणों में है, अर्थात् DefaultMergeEventListener::cascadeOnMerge और DefaultMergeEventListener::copyValues । आइए, हाइबरनेट के प्रमुख डेवलपर्स में से एक, व्लाद मिखेल का सीधा भाषण सुनें:

CopyValues ​​मेथड कॉल में, हाइड्रेटेड स्टेट को फिर से कॉपी किया जाता है, इसलिए एक नया एरे को बेवजह बनाया जाता है, इसलिए CPU साइकिल को बर्बाद किया जाता है। यदि इकाई में बाल संघ हैं और मर्ज संचालन को भी माता-पिता से बाल संस्थाओं में कैस्केड किया जाता है, तो ओवरहेड और भी अधिक होता है क्योंकि प्रत्येक बाल इकाई एक मर्जवेंट का प्रचार करेगी और चक्र जारी है।

दूसरे शब्दों में, ऐसा काम किया जा रहा है जो आप नहीं कर सकते। परिणामस्वरूप, इसके प्रदर्शन में सुधार करते हुए हमारे कोड को सरल बनाया जा सकता है:

 @Transactional public BankAccount updateRate(Long id, BigDecimal rate) { BankAccount account = repo.findById(id).orElseThrow(NPE::new); account.setRate(rate); return account; } 

बेशक, किसी और के कोड को विकसित और प्रूफ करते समय इसे ध्यान में रखना असुविधाजनक है, इसलिए हम वायरफ्रेम स्तर पर परिवर्तन करना चाहते हैं ताकि JpaRepository::save विधि अपने हानिकारक गुणों JpaRepository::save खो दे। क्या यह संभव है?

 // @Transactional public <S extends T> S save(S entity) { if (entityInformation.isNew(entity)) { em.persist(entity); return entity; } else { return em.merge(entity); } } // @Transactional public <S extends T> S save(S entity) { if (entityInformation.isNew(entity)) { em.persist(entity); return entity; } else if (!em.contains(entity)) { return em.merge(entity); } return entity; } 

हालाँकि, परिष्कृत पाठक को शायद पहले से ही कुछ सूझ रहा था। वास्तव में, यह परिवर्तन कुछ भी नहीं तोड़ देगा, लेकिन केवल साधारण मामले में जब कोई बाल संस्था नहीं है:

 @Entity public class BankAccount { @Id Long id; @Column BigDecimal rate = BigDecimal.ZERO; } 

अब मान लीजिए कि इसका मालिक खाते से बंधा हुआ है:

 @Entity public class BankAccount { @Id Long id; @Column BigDecimal rate = BigDecimal.ZERO; @ManyToOne @JoinColumn(name = "user_id") User user; } 

एक विधि है जो आपको उपयोगकर्ता को खाते से डिस्कनेक्ट करने और बाद में नए उपयोगकर्ता को स्थानांतरित करने की अनुमति देती है:

 @Transactional public BankAccount changeUser(Long id, User newUser) { BankAccount account = repo.findById(id).orElseThrow(NPE::new); account.setUser(newUser); return repo.save(account); } 

अब क्या होगा? em.contains(entity) जाँच करना सही होगा, जिसका अर्थ है कि em.merge(entity) को नहीं कहा जाएगा। यदि User इकाई कुंजी अनुक्रम (सबसे सामान्य मामलों में से एक) के आधार पर बनाई गई है, तो यह तब तक नहीं बनाई जाएगी जब तक कि लेनदेन पूरा नहीं हो जाता है (या Session::flush मैन्युअल रूप से कहा जाता है), अर्थात उपयोगकर्ता डीईटीईडी राज्य में होगा, और उसकी मूल इकाई ( खाता) - व्यक्तिगत अवस्था में। कुछ मामलों में, यह एप्लिकेशन लॉजिक को तोड़ सकता है, जो कि हुआ है:

02/03/2018 DATAJPA-931 का विराम रिपोजिटरी के साथ विलय

इस संबंध में, CrudRepository में मौजूदा संस्थाओं के लिए किए गए प्रत्यावर्तन प्रत्यावर्तन :: सेव बनाए गए और परिवर्तन किए गए: DATAJPA-931 ।

अंधा CrudRepository :: findById

हम समान डेटा मॉडल पर विचार करना जारी रखते हैं:

 @Entity public class User { @Id Long id; // ... } @Entity public class BankAccount { @Id Long id; @ManyToOne @JoinColumn(name = "user_id") User user; } 

एप्लिकेशन में एक विधि है जो निर्दिष्ट उपयोगकर्ता के लिए एक नया खाता बनाती है:

 @Transactional public BankAccount newForUser(Long userId) { BankAccount account = new BankAccount(); userRepository.findById(userId).ifPresent(account::setUser); //<---- return accountRepository.save(account); } 

संस्करण 2 के साथ। * तीर द्वारा इंगित एंटीपैटर्न इतना हड़ताली नहीं है - यह पुराने संस्करणों पर अधिक स्पष्ट रूप से देखा जाता है:

 @Transactional public BankAccount newForUser(Long userId) { BankAccount account = new BankAccount(); account.setUser(userRepository.findOne(userId)); //<---- return accountRepository.save(account); } 

 select u.id, u.name from user u where u.id = ? call next value for hibernate_sequence insert into bank_account (id, /*…*/ user_id) values (/*…*/) 

पहला अनुरोध हमें कुंजी द्वारा उपयोगकर्ता को मिलता है। अगला, हमें डेटाबेस से नवजात खाते की कुंजी मिलती है और इसे तालिका में सम्मिलित करते हैं। और केवल एक चीज जो हम उपयोगकर्ता से लेते हैं वह है कुंजी, जो हमारे पास पहले से ही एक विधि तर्क के रूप में है। दूसरी ओर, BankAccount में "उपयोगकर्ता" फ़ील्ड शामिल है और हम इसे खाली नहीं छोड़ सकते हैं (जैसा कि सभ्य लोग हम योजना में प्रतिबंध सेट करते हैं)। अनुभवी डेवलपर्स शायद पहले से ही एक रास्ता देखते हैं और एक मछली खाओ, और एक घोड़े की सवारी करो उपयोगकर्ता और अनुरोध दोनों को प्राप्त करें:

 @Transactional public BankAccount newForUser(Long userId) { BankAccount account = new BankAccount(); account.setUser(userRepository.getOne(userId)); //<---- return accountRepository.save(account); } 

JpaRepository::getOne उस कुंजी पर एक आवरण देता है जिसमें जीवित "इकाई" के समान प्रकार होता है। यह कोड केवल दो अनुरोध देता है:

 call next value for hibernate_sequence insert into bank_account (id, /*…*/ user_id) values (/*…*/) 

जब एक इकाई का निर्माण किया जा रहा है तो कई क्षेत्रों में एक-से-एक / एक-से-एक संबंध होते हैं, यह तकनीक डेटाबेस पर लोड को कम करने और कम करने में मदद करेगी।

HQL क्वेरी को निष्पादित करना

यह एक अलग और दिलचस्प विषय है :)। डोमेन मॉडल समान है और इस तरह का अनुरोध है:

 @Query("select count(ba) " + " from BankAccount ba " + " join ba.user user " + " where user.id = :id") long countUserAccounts(@Param("id") Long id); 

"शुद्ध" HQL पर विचार करें:

 select count(ba) from BankAccount ba join ba.user user where user.id = :id 

जब इसे निष्पादित किया जाता है, तो निम्न SQL क्वेरी बनाई जाएगी:

 select count(ba.id) from bank_account ba inner join user u on ba.user_id = u.id where u.id = ? 

एक बुद्धिमान जीवन और एसक्यूएल डेवलपर्स की अच्छी समझ से भी यहां समस्या तुरंत स्पष्ट नहीं होती है: उपयोगकर्ता कुंजी द्वारा inner join user_id खातों को गायब inner join वाले उपयोगकर्ता_ के साथ चयन से बाहर कर देगा (और अच्छे तरीके से, उन्हें सम्मिलित करना स्कीमा स्तर पर निषिद्ध होना चाहिए, जिसका अर्थ है कि user तालिका में शामिल होना आम तौर पर नहीं है। की जरूरत है। अनुरोध को सरल (और त्वरित) किया जा सकता है:

 select count(ba.id) from bank_account ba where ba.user_id = ? 

HQL का उपयोग करके c में इस व्यवहार को आसानी से प्राप्त करने का एक तरीका है:

 @Query("select count(ba) " + " from BankAccount ba " + " where ba.user.id = :id") long countUserAccounts(@Param("id") Long id); 

यह विधि एक "लाइट" अनुरोध बनाती है।

क्वेरी बनाम विधि सार

स्प्रिंग डेटा की मुख्य विशेषताओं में से एक विधि नाम से एक क्वेरी बनाने की क्षमता है, जो बहुत सुविधाजनक है, विशेष रूप से इंटेलीज आईडीईए से स्मार्ट ऐड-ऑन के संयोजन में। पिछले उदाहरण में वर्णित क्वेरी को आसानी से लिखा जा सकता है:

 // @Query("select count(ba) " + " from BankAccount ba " + " where ba.user.id = :id") long countUserAccounts(@Param("id") Long id); // long countByUserAccount_Id(Long id); 

यह सरल, और छोटा, और अधिक पठनीय, और सबसे महत्वपूर्ण बात लगती है - आपको अनुरोध को स्वयं देखने की आवश्यकता नहीं है। मैंने विधि का नाम पढ़ा - और यह पहले से ही स्पष्ट है कि यह क्या और कैसे चुनता है। लेकिन शैतान यहाँ विवरण में है। @Query के साथ चिह्नित विधि के लिए अंतिम प्रश्न हमने पहले ही देखा है। दूसरे मामले में क्या होगा?

 select count(ba.id) from bank_account ba left outer join // <--- !!!!!!! user u on ba.user_id = u.id where u.id = ? 

"क्या बात है!" - डेवलपर एक्सक्लूसिव होगा। आखिरकार, हम पहले ही देख चुके हैं वायोलिन बाजनेवाला join जरूरत नहीं है।

कारण अभियुक्त है:

• JPADATAJPA-729 एक सिंगल टेबल की गिनती के लिए अनावश्यक OUTER JOIN किया जाता है
• जब कोई इस्तेमाल किया जा सकता था तब DATAJPA-1238 अनावश्यक रूप से छोड़ दिया गया

यदि आपने अभी तक पैच किए गए संस्करणों में अपग्रेड नहीं किया है, और टेबल से जुड़कर यहां और अब अनुरोध को धीमा कर देते हैं, तो निराशा न करें: दर्द को कम करने के दो तरीके हैं:

• एक अच्छा तरीका optional = false जोड़ना है (यदि सर्किट अनुमति देता है):

  
  

   @Entity public class BankAccount { @Id Long id; @ManyToOne @JoinColumn(name = "user_id", optional = false) User user; } 

  
  

• बैसाखी तरीका User इकाई कुंजी के समान प्रकार का एक स्तंभ जोड़ने और user क्षेत्र के बजाय प्रश्नों में उपयोग करने के लिए है:

  
  

   @Entity public class BankAccount { @Id Long id; @ManyToOne @JoinColumn(name = "user_id") User user; @Column(name = "user_id", insertable = false, updatable = false) Long userId; } 

  
  

  अब रिक्वेस्ट-फ्रॉम-मैथड निकेलर:

  
  

   long countByUserId(Long id); 

  
  

  देता है

  
  

   select count(ba.id) from bank_account ba where ba.user_id = ? 

  
  

  हमने क्या हासिल किया।

  
  

नमूना लेने की सीमा

हमारे उद्देश्यों के लिए, हमें चयन को सीमित करने की आवश्यकता है (उदाहरण के लिए, हम *RepositoryCustom विधि) से Optional लौटना चाहते हैं:

 select ba.* from bank_account ba order by ba.rate limit ? 

अब जावा:

 @Override public Optional<BankAccount> findWithHighestRate() { String query = "select b from BankAccount b order by b.rate"; BankAccount account = em .createQuery(query, BankAccount.class) .setFirstResult(0) .setMaxResults(1) .getSingleResult(); return Optional.ofNullable(bankAccount); } 

निर्दिष्ट कोड में एक अप्रिय विशेषता है: इस घटना में कि अनुरोध एक खाली चयन लौटा, एक अपवाद फेंक दिया जाएगा

 Caused by: javax.persistence.NoResultException: No entity found for query 

जिन परियोजनाओं में मैंने देखा, उन्हें दो मुख्य तरीकों से हल किया गया था:

• Optonal.empty() अपवाद Optonal.empty() और Optonal.empty() उन्नत विधि के लिए एक अनुरोध के साथ एक Optonal.empty() गुजरने की तरह, Optonal.empty() और अधिक उन्नत तरीकों से लौटने से बदलाव के साथ प्रयास करें
• पहलू जिसमें रिपॉजिटरी के तरीकों ने लिपटे Optional लौटाया

और बहुत कम ही, मैंने सही समाधान देखा:

 @Override public Optional<BankAccount> findWithHighestRate() { String query = "select b from BankAccount b order by b.rate"; return em.unwrap(Session.class) .createQuery(query, BankAccount.class) .setFirstResult(0) .setMaxResults(1) .uniqueResultOptional(); } 

EntityManager JPA मानक का हिस्सा है, जबकि Session हाइबरनेट का है और IMHO एक अधिक उन्नत उपकरण है, जिसे अक्सर भुला दिया जाता है।

[कभी-कभी] हानिकारक सुधार

जब आपको "मोटी" इकाई से एक छोटा क्षेत्र प्राप्त करने की आवश्यकता होती है, तो हम यह करते हैं:

 @Query("select a.available from BankAccount a where a.id = :id") boolean findIfAvailable(@Param("id") Long id); 

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

 @Override @Transactional public boolean checkAccount(Long id) { BankAccount acc = repository.findById(id).orElseThow(NPE::new); // ... return repository.findIfAvailable(id); } 

यह कोड कम से कम 2 अनुरोध करता है, हालांकि दूसरे को टाला जा सकता है:

 @Override @Transactional public boolean checkAccount(Long id) { BankAccount acc = repository.findById(id).orElseThow(NPE::new); // ... return repository.findById(id) //    .map(BankAccount::isAvailable) .orElseThrow(IllegalStateException::new); } 

निष्कर्ष सरल है: पहले स्तर के कैश की उपेक्षा न करें, एक लेनदेन के ढांचे के भीतर, केवल पहला JpaRepository::findById डेटाबेस को संदर्भित करता है, JpaRepository::findById पहले स्तर का कैश हमेशा चालू रहता है और एक सत्र से बंधा होता है, जो आमतौर पर वर्तमान लेनदेन से बंधा होता है।

खेलने के लिए टेस्ट (रिपॉजिटरी का लिंक लेख की शुरुआत में दिया गया है):

• संकीर्ण इंटरफ़ेस परीक्षण: InterfaceNarrowingTest
• एक समग्र कुंजी के साथ एक उदाहरण के लिए परीक्षण करें: EntityWithCompositeKeyRepositoryTest
• अतिरिक्त CrudRepository::save परीक्षण करें CrudRepository::save : ModifierTest.java
• अंधा परीक्षण CrudRepository::findById : ChildServiceImplTest
• अनावश्यक left join परीक्षण में left join : BankAccountControlRepositoryTest

CrudRepository::save पर एक अतिरिक्त कॉल की लागत की गणना RedundantSaveBenchmark का उपयोग करके की जा सकती है। इसे BenchmarkRunner वर्ग का उपयोग करके लॉन्च किया गया है।