oluexpert99 opened a new pull request, #6185:
URL: https://github.com/apache/fineract/pull/6185
- Since FINERACT-2624 switched report-parameter substitution from
string interpolation to
JDBC bind variables, a placeholder that appears in a report's SQL
but is not one of that
report's own declared parameters binds as a String. On PostgreSQL,
comparing a bigint
column to a bound character varying raises "operator does not exist:
bigint = character
varying" and the query fails with HTTP 403; MySQL and MariaDB coerce
the types silently,
which is why CI does not see it.
- The stock loanOfficerIdSelectAll option lookup is the clearest case.
Its SQL filters
"... and o.id = ${officeId}", where officeId is supplied by the
parent parameter, so
ReadReportingServiceImpl.getSQLtoRun loads the format types of
loanOfficerIdSelectAll,
finds no entry for officeId, and castParamValue falls through to
returning the raw
String. Every report whose Loan Officer dropdown cascades off office
is therefore empty
on a PostgreSQL deployment.
- When no format type is declared, infer a numeric bind for a plain
integer value so
strict engines compare correctly. The inference is deliberately
narrow: the value must
match -?(0|[1-9]\d*), so currency codes, free text and identifiers
carrying leading
zeros such as 000123 keep their String binding and are not mangled
into numbers.
Declared NUMBER, INTEGER and DATE types are untouched.
- Add ReadReportingServiceImplTest, which captures the values bound
for a report whose SQL
cascades on ${officeId}: an untyped "1" must arrive as a Long, while
"USD" and "000123"
must stay Strings and a declared number type must keep working. The
first case fails on
the unfixed code with "expected: java.lang.Long<1> but was:
java.lang.String<1>"; the
other three assert the narrowness of the inference and hold either
way by design.
## Description
Describe the changes made and why they were made. (Ignore if these details
are present on the associated Apache Fineract JIRA ticket.)
## Checklist
Please make sure these boxes are checked before submitting your pull request
- thanks!
- [ ] Write the commit message as per [our
guidelines](https://github.com/apache/fineract/blob/develop/CONTRIBUTING.md#pull-requests)
- [ ] Acknowledge that we will not review PRs that are not passing the build
_("green")_ - it is your responsibility to get a proposed PR to pass the build,
not primarily the project's maintainers.
- [ ] Create/update [unit or integration
tests](https://fineract.apache.org/docs/current/#_testing) for verifying the
changes made.
- [ ] Follow our [coding
conventions](https://cwiki.apache.org/confluence/display/FINERACT/Coding+Conventions).
- [ ] Add required Swagger annotation and update API documentation at
fineract-provider/src/main/resources/static/legacy-docs/apiLive.htm with
details of any API changes
- [ ] [This PR must not be a "code
dump"](https://cwiki.apache.org/confluence/display/FINERACT/Pull+Request+Size+Limit).
Large changes can be made in a branch, with assistance. Ask for help on the
[developer mailing list](https://fineract.apache.org/#contribute).
- [ ] If merging this PR resolves a JIRA issue, I will mark that issue as
resolved and set "Fix Version/s" appropriately.
Your assigned reviewer(s) will follow our [guidelines for code
reviews](https://cwiki.apache.org/confluence/display/FINERACT/Code+Review+Guide).
--
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]
