Originally posted by: crook
We’re considering using liquibase to manage our database schema from development environments all the way to production. Our system is fairly complex; we have many applications which have their own schemas. Each application depends on a number of modules, some of which also have their own schemas. Some of the module schemas are shared between applications.
Are you using ORM at all? If you are, why do you have cross-schema dependencies?
Split out your domain model into a 1-1 mapping between domain repositories and schemas (so, say you have a common user schema - have a foo-model-users module that manages its schema changes, and a foo-model-widgets module that manages its schema changes… etc.) You could make each module have it’s own basic spring config that handles DB mitration on app startup to match the version of the module you are loading… etc.
If you are saying you have independent pieces of software that are not isolated from changes in other pieces of software (ie a change in one module breaks another module) your code sounds like it is ripe for a rethinking. That’s a big “ugh” factor to have to fight against all the time when making changes (see also: technical debt).
EDIT: after reading your post again, it isn’t clear if you are asking about running multiple changelogs (1 per module) and doing stuff at runtime but with a codebase that is sufficiently well split up or about the case I described above…
Are you asking specifically about how to implement something that will do the updates? What frameworks are you using? (I.e spring? Guide? Etc)