KRYSTALM7 opened a new issue, #46:
URL: https://github.com/apache/fineract-loan-origination/issues/46
## Summary
Existing V1–V6 Flyway migrations surfaced several data-integrity gaps
between the database schema and the JPA entity layer. This issue tracks
fixing those
gaps; some are already addressed, others still need follow-up.
## Issues found and fixed
- **Missing `version` column on `loan_application`** — `LoanApplication`
entity declares
`@Version private Long version` for optimistic locking, but no migration
ever created
this column. With `ddl-auto: validate`, this causes a schema validation
failure at
startup. Fixed in V1.
- **`applicant_profile` not enforced as 1:1 with `loan_application`** — the
FK existed
but without a `UNIQUE` constraint, so the true one-to-one relationship was
only
enforced by an app-level `existsByApplication` check, which is
race-condition-prone
under concurrent requests. Fixed with `UNIQUE` on `application_id`.
- **`credit_score` not enforced as 1:1** — same issue;
`CreditScoringService` is designed
to be idempotent (score never recomputed), but nothing at the DB level
prevented
duplicate rows. Fixed with `UNIQUE` on `application_id`.
- **Missing indexes on foreign-key columns** — Postgres does not auto-index
FK columns.
`required_document.application_id` and
`applicant_profile.fineract_client_id` (combined
with `tenant_id`) had no supporting index despite being actively queried —
the latter
is now a hot path for the new customer-scoped "my applications" lookup.
## Migration note
Local dev databases must be dropped and recreated before running the app
against these
updated migrations, since Flyway validates checksums of already-applied
migrations.
--
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]
