Remove dependency on LiquiBase

[jesperpedersen]

Use Hibernate and a .sql script instead

[rvansa]

And why do you want to drop ability to migrate versions? Do you intend to do the schema changes manually?

[jesperpedersen]

Type mappings have changed between Hibernate 5 and 6, so we should just let it handle it upon install. And, then apply a .sql script with our other requirements

[Sanne]

Type mappings have changed between Hibernate 5 and 6, so we should just let it handle it upon install. And, then apply a .sql script with our other requirements

Could you elaborate on this please as I'm curious to learn more about the tooling requirements. Isn't that precisely what Liquibase is supposed to help with?

I wouldn't recommend to "let Hibernate handle it" unless you're fine with data loss (e.g. a new major release which isn't meant to migrate data over from a previous instance). What we normally suggest is to let Hibernate ORM "handle it" on a dev environment to observe what it would do, but then have someone with DB knowledge review those changes individually and use this information to guide creating the migration scripts.

I wouldn't let Hibernate ORM do anything other than "validate" on production data directly: it's not designed for this and we don't do data migration testing.

[Sanne]

P.S. I realize this is labour intensive and rather annoying to do, but Hibernate ORM upgrades that require such intervention should be extremely rare.

[jesperpedersen]

That is precisely the point - don't touch my DB at all, or create a skeleton with DDL + custom scripts.

Production level databases are locked, and applications are not allowed to do changes through DDL - see https://www.postgresql.org/docs/current/sql-grant.html for starters. So, having to rely on a DB role that allows the application (through LiquiBase/Flyway) to make changes is basically a no-go. Data is king, applications - and their tech - comes and go

[jesperpedersen]

And, this should be a single switch in the application configuration