adamsaghy commented on code in PR #6106:
URL: https://github.com/apache/fineract/pull/6106#discussion_r3569447199
##########
fineract-accounting/src/main/java/org/apache/fineract/accounting/producttoaccountmapping/service/ProductToGLAccountMappingReadPlatformServiceImpl.java:
##########
@@ -257,21 +259,23 @@ public List<ChargeToGLAccountMapper>
fetchPenaltyToIncomeAccountMappingsForSavin
private List<ChargeToGLAccountMapper>
fetchChargeToIncomeAccountMappings(final PortfolioProductType
portfolioProductType,
final Long loanProductId, final boolean penalty) {
- final List<ProductToGLAccountMapping> mappings = penalty
- ?
productToGLAccountMappingRepository.findAllPenaltyMappings(loanProductId,
portfolioProductType.getValue())
- :
productToGLAccountMappingRepository.findAllFeeMappings(loanProductId,
portfolioProductType.getValue());
-
- List<ChargeToGLAccountMapper> chargeToGLAccountMappers =
mappings.isEmpty() ? null : new ArrayList<>();
- for (final ProductToGLAccountMapping mapping : mappings) {
- final GLAccountData gLAccountData = new
GLAccountData().setId(mapping.getGlAccount().getId())
-
.setName(mapping.getGlAccount().getName()).setGlCode(mapping.getGlAccount().getGlCode());
- final ChargeData chargeData =
ChargeData.builder().id(mapping.getCharge().getId()).name(mapping.getCharge().getName())
- .penalty(mapping.getCharge().isPenalty()).build();
- final ChargeToGLAccountMapper chargeToGLAccountMapper = new
ChargeToGLAccountMapper().setCharge(chargeData)
- .setIncomeAccount(gLAccountData);
- chargeToGLAccountMappers.add(chargeToGLAccountMapper);
- }
- return chargeToGLAccountMappers;
+ // The accounting module is decoupled from the charge domain, so we
cannot navigate a Charge association in
+ // JPQL. We read the charge -> income-account rows via JdbcTemplate
rather than a JPA native query: EclipseLink
+ // does not bind Spring Data ":name" parameters in native queries (it
expects "#name"), which caused the raw
+ // markers to reach the database. JdbcTemplate uses plain JDBC
positional binding and works on all supported
+ // databases. The GL account fields are selected via a join on
acc_gl_account so we avoid a per-row lookup.
+ // Column order: [0] gl_account_id, [1] gl_account_name, [2] gl_code,
[3] charge_id, [4] charge_name.
+ final String sql = "select ga.id, ga.name, ga.gl_code, c.id, c.name "
+ "from acc_product_mapping apm "
Review Comment:
I don’t like this idea. You say we are decoupling the charge, but in
reality, it doesn’t happen. Just because you are using a workaround to use
native SQL queries it still means the responsibility remains here: Fetch the
ChargeData via the charge service (the interface can and the DTO can remain in
the accounting module, while the implementation can go into the charge module).
Let’s decide whether the accounting module depends on the charge or the
charge depends on the accounting. One of them must, because there is common
logic.
--
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]
