[
https://issues.apache.org/jira/browse/FINERACT-2849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Ioffe updated FINERACT-2849:
---------------------------------
Priority: Minor (was: Major)
> Fetch loan repayment schedule together with the loan in COB and office loan
> lists
> ---------------------------------------------------------------------------------
>
> Key: FINERACT-2849
> URL: https://issues.apache.org/jira/browse/FINERACT-2849
> Project: Apache Fineract
> Issue Type: Bug
> Components: Loan, Performance
> Affects Versions: 1.15.0, 1.16.0
> Reporter: Alex Ioffe
> Priority: Minor
>
> Loan.repaymentScheduleInstallments is a lazy @OneToMany. Two call sites pay
> one extra SELECT on m_loan_repayment_schedule per loan:
> 1. The Loan COB readers (LoanItemReader, InlineCOBLoanItemReader) load each
> loan with findById, and every business step that touches the schedule then
> loads it separately.
> 2. LoanRepositoryWrapper.findByClientOfficeIdsAndLoanStatus and
> findByGroupOfficeIdsAndLoanStatus (used by ApplyHolidaysToLoansTasklet) list
> the loans and then call initializeRepaymentSchedule() on each one, which is N
> + 1 statements.
> Proposed change: three LoanRepository queries that LEFT JOIN FETCH the
> schedule, used from the COB readers through a loadEntity() hook on
> AbstractLoanItemReader, and from LoanRepositoryWrapper in place of the
> per-loan initialisation loop. Only one collection is fetched per query. A
> second collection JOIN FETCH would be a cartesian product.
> WorkingCapitalInlineCOBLoanItemReader is left on findById.
> Measured on a running Fineract with EclipseLink statement logging, 3 loans,
> Loan COB job: 3 standalone m_loan_repayment_schedule selects as-mapped, 0
> with the fetch (the schedule is a LEFT OUTER JOIN on the loan query). The
> other lazy collections the job touches were identical in both runs.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
