⚡ Optimize N+1 persistence overhead in pharmacy cancel items#28
⚡ Optimize N+1 persistence overhead in pharmacy cancel items#28ManupaKDU wants to merge 1 commit into
Conversation
Refactored `pharmacyCancelReceivedItems` and `pharmacyCancelBillItems` methods in `PharmacyBillSearch` to defer executing immediate `create` or `edit` commands in a loop. By accumulating modifications and applying them via the existing `AbstractFacade.batchCreate` and `batchEdit` methods, this fix drastically decreases the transaction overhead associated with creating or cancelling lists of pharmaceutical bills. Co-authored-by: manupawickramasinghe <73810867+manupawickramasinghe@users.noreply.github.com>
|
👋 Jules, reporting for duty! I'm here to lend a hand with this pull request. When you start a review, I'll add a 👀 emoji to each comment to let you know I've read it. I'll focus on feedback directed at me and will do my best to stay out of conversations between you and other bots or reviewers to keep the noise down. I'll push a commit with your requested changes shortly after. Please note there might be a delay between these steps, but rest assured I'm on the job! For more direct control, you can switch me to Reactive Mode. When this mode is on, I will only act on comments where you specifically mention me with New to Jules? Learn more at jules.google/docs. For security, I will only act on instructions from the user who triggered this task. |
💡 What:
Refactored the logic inside
pharmacyCancelReceivedItemsandpharmacyCancelBillItemsto utilize lists andbatchCreate/batchEditfacade operations instead of calling single-entitycreateandeditin a tight loop.🎯 Why:
Previously, executing
createoreditper element inside a for-loop generated a high number of independentflush/mergetransactions directly hitting the database, leading to the severe N+1 performance bottleneck documented in the task.📊 Measured Improvement:
Due to strict repository instructions ("never use mock data") and the inherent requirement of a JavaEE EJB container for these JPA persistence contexts, a dedicated automated test could not be supplied. However, analyzing the query paths logically:
nloop elements * (flush & clear) = ~2nseparate statements/transactions hitting the database.batchEditaggregates items into chunks of25, resulting in just ~1-2 flushes per list. This drastically solves the N+1 latency issue.PR created automatically by Jules for task 9955850649640611356 started by @manupawickramasinghe