Alex Ioffe created FINERACT-2849:
------------------------------------
Summary: 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
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)
