Best practices for multiple applications with shared schemas?

Hi all,
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.

There seems to be a number of ways you could go about implementing this in liquibase. For instance, a databasechangelog per schema, a databasechangelog per db instance, etc… We have an idea of how we want to implement this but I’m wondering if others have used liquibase in a similar environment? Do you have any words of wisdom, best practices or gotchas to share?

Thanks in advance!

I have generally done a changelog per schema, but that is also in cases where there are no cross-schema dependencies.

Not knowing the specifics of your environment, I generally suggest minimizing dependencies that span changelogs.  They can be done, but it can become confusing as to where changes go, the order they are applied in, etc. 

Nathan

E

Originally posted by: crook

Hi all,
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)

Thanks for the replies! After some deeper thought we have decided to go with changelog-per-schema and also to avoid cross-schema dependencies.

How did you manage to not have dependencies between schemas?
You don’t declare the FKs?
Because in best case usually always there is a “common” schema that’s difficult to don’t depend on it.

Cheers,