[
https://issues.apache.org/jira/browse/FINERACT-2704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18127475#comment-18127475
]
Sonigra Bhavya Hemendrabhai commented on FINERACT-2704:
-------------------------------------------------------
I'm stepping back from this ticket. I drafted a plan and built a merged core
baseline, but when I generated the actual migration and ran it on fresh
databases I kept getting foreign key / "table doesn't exist" failures that I
couldn't isolate, so I can't vouch for schema equivalence or the upgrade path.
Notes for whoever picks it up:
* Likely problem area (unverified): ordering of FK creation vs the tables they
reference. A baseline probably needs all \{{createTable}} first, with FKs and
indexes in a final phase, like \{{0146_add_final_constraints}} does.
* Core 0241 has \{{context="mysql"}}, so it never runs on Postgres. The guard
needs a per-DB check on the last legacy changeset: id \{{1}} /
\{{0240_add_retained_earning_global_configuration.xml}} on Postgres, id \{{17}}
/ \{{0241_set_datetime_precision.xml}} on MySQL/MariaDB. Match id + author +
filename.
* \{{0146_add_final_constraints.xml}} runs last via the final changelog and
should stay out of the baseline.
* Core 0242+, investor 0023+ and working-capital 0051+ are post-1.15 and must
not be renamed, since Liquibase identity includes the file path.
* A regex-based merge breaks Liquibase's XSD ordering, so a parser-based merge
is needed.
* The app maps MariaDB to the same \{{mysql}} context as MySQL.
> re-baseline database migrations
> -------------------------------
>
> Key: FINERACT-2704
> URL: https://issues.apache.org/jira/browse/FINERACT-2704
> Project: Apache Fineract
> Issue Type: Improvement
> Components: Build
> Reporter: Adam Monsen
> Priority: Minor
> Labels: beginner
>
> {{./gradlew devRun}} is pretty slow for a fresh database. Part of the reason
> is that many liquibase database migrations need to run.
> Re-baseline our db migrations as of the current release (1.15.0): create an
> empty database, run all migrations, then re-create initial schema and initial
> data files. Leave any schema/data migrations created post-1.15.0 in place,
> but you may re-number all initial and migration files starting at 0001.
> We'll plan on doing this once per release, back to the last supported/stable
> release.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
