Hi everyone, I am currently working on FINERACT-2704 (DB re-baseline for 1.15.0) and have reached a milestone where community feedback is essential before proceeding.
*Current Progress* - Generated consolidated 0001_initial_schema.sql (DDL) and 0002_initial_data.sql (DML) for both PostgreSQL and MariaDB/MySQL, capturing the full 1.15.0 state. - Cleaned the pg_dump output by converting COPY ... FROM STDIN blocks to INSERT INTO statements and adding setval() calls to reset sequences. - A fresh ./gradlew devRun now starts in approximately 45 seconds, with all unit tests passing. - Implemented and validated a *Hybrid (Core-Only)* approach. After discovering the monolithic dump broke module scripts, I isolated a Core-only dump. Module changelogs (e.g., fineract-loan, fineract-investor) now run cleanly on top of this. This is working end-to-end on both PostgreSQL and MariaDB. *PR:* https://github.com/apache/fineract/pull/6309 <https://github.com/apache/fineract/pull/6309?utm_source=gemini> *JIRA:* https://issues.apache.org/jira/browse/FINERACT-2704 <https://issues.apache.org/jira/browse/FINERACT-2704?utm_source=gemini> *Open Architectural Decisions* *1. Monolithic vs. Modular Baseline* The original monolithic pg_dump captured all tables (Core + modules), causing module-level changelogs to fail with a relation already exists error. We have three potential paths forward: - *Option A (Monolithic):* Core dump includes all module tables; module changelogs are deleted. This maximizes simplicity but breaks module decoupling and represents a massive scope change. - *Option B (Hybrid Core-Only - Current):* Core dump contains only Core tables. Module changelogs continue to run on top unchanged. This preserves module ownership and is already fully functional. - *Option C (Strict Modular):* Each module receives its own baseline dump. This provides full decoupling but introduces extreme complexity due to cross-module foreign keys. This is likely out of scope for this JIRA. *2. Upgrade-Safe vs. Clean-Break* - *Upgrade-Safe (Current):* Existing databases skip the SQL dump via Liquibase preConditions and continue from their current state. However, post-1.15.0 migration files (currently 0242+) cannot be renumbered. Liquibase tracks filenames in DATABASECHANGELOG, so renaming them would trigger accidental re-execution on existing databases. - *Clean-Break:* The re-baseline only supports fresh installations. This allows us to renumber all post-1.15.0 migrations sequentially from 0003 (as originally suggested in the JIRA), but existing deployments would require a complete reinstall. *Questions for the Community* 1. Is Option B (Hybrid Core-Only) the preferred approach, or should we pursue Option A or C? 2. Should we maintain support for in-place upgrades (the current state), or is a clean-break strategy acceptable? 3. If we proceed with a clean break, should post-1.15.0 migrations be renumbered starting from 0003? 4. Should module changelogs be considered in scope for FINERACT-2704, or deferred to a follow-up ticket? I am happy to adapt the implementation based on the community's consensus. Looking forward to your thoughts! Best regards, Bhavya Sonigra
