Mk9894 commented on code in PR #3158:
URL: https://github.com/apache/fineract/pull/3158#discussion_r1191346581
##########
fineract-provider/src/main/java/org/apache/fineract/portfolio/savings/service/SavingsAccountReadPlatformServiceImpl.java:
##########
@@ -1267,6 +1270,99 @@ public Collection<SavingsAccountTransactionData>
retrieveAllTransactions(final L
return this.jdbcTemplate.query(sql, this.transactionsMapper, new
Object[] { savingsId, depositAccountType.getValue() }); // NOSONAR
}
+ @Override
+ public Page<SavingsAccountTransactionData> retrieveAllTransactions(final
Long savingsId, DepositAccountType depositAccountType,
+ SearchParameters searchParameters, LocalDate fromDate, LocalDate
toDate,
+ @DecimalMin(value = "0", message = "must be greater than or equal
to 0") BigDecimal fromAmount,
+ @DecimalMin(value = "0", message = "must be greater than or equal
to 0") BigDecimal toAmount, String transactionType) {
+
+ final StringBuilder sqlBuilder = new StringBuilder(200);
Review Comment:
Hello @galovics , I acknowledge your preference for using JPQL for
implementation. However, it's important to note that there is a possibility of
compatibility issues with the other APIs of the transaction endpoint.
Specifically, the retrieveOne function of the transaction API returns a
response of Type SavingsAccountTransactionData, which is a custom type. In
contrast, when using JPQL, we need to return SavingsAccountTransaction as the
data type, which is the entity itself. This could potentially lead to the
return response being incompatible with other transaction endpoints. I would
greatly appreciate hearing your thoughts on this.
Thanks
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
