Flyway: disable DDL generation from EclipseLink
This is a successor issue to #5862. This kind of relates to #5854. This should be read by @pdurbin, @MrK191, @donsizemore and @djbrooke at least.
Since the introduction of Flyway in #5344, only minor modifications happened to the schema. In #5822 a new column has been added and since it had been merged, the develop branch no longer deploys on new "installations".
Some background on the cause: EclipseLink ORM generates a DDL script from all models on startup and (due to this setting in persistance.xml) creates new tables when not existing. It does not update existing tables. This job is left to Flyway, which is one reason why it had been introduced.
Flyway throws exceptions due to a conflict, trying to change something already present. In #5822, a new column should be added, but on new deployments, EclipseLink already generated the mapping. Thus the deployment fails.
How to get along with this: Obviously, one could just use workarounds as #5866 does. It would be better to have a discussion and decision on how to deal with database model, mappings, EclipseLink and Flyway in the future, write down a process and adapt.
IMHO there is only one "good" solution, but this is only a proposal and needs to be discussed and/or modified:
- Do not let EclipseLink generate DDL anymore.
- Get a base model mapping in the codebase as a proper baseline. This, ideally, should be the exact mapping as it has been when Flyway had been merged.
- Continue to write migrations in SQL or Java with Flyway, as already done. Document this part of the process if not already done sufficiently.
- To ensure 100% compatibility between tables and models, the mapping - now maintained with Flyway as migration files - needs to be validated regularly. This is an ideal task for CI on jenkins.dataverse.org.
It might be an option to switch from EclipseLink JPA to Hibernate JPA as it offers easier to use validation mechanisms than EclipseLink does.