what about dblinks?

I think you should use a changelog parameter in the changelog itself to avoid saving the password in SVN. You’ll have to pass it in at runtime, but that is better security.

There isn’t any built-in direct support in liquibase for handling dependencies, it is left as an exercise for the user :slight_smile:  The main reason we don’t handle it directly is because there are so many different ways people want it to work.

Generally, it is best to avoid dependencies if at all possible. You can break up a changelog into multiple files for easier management, but it is still logically one big file that is executed sequentially. 

If you have dependencies, you have a couple options I can think of off hand:

  1. use the changeSetExecuted precondition to at least check that the precondition from the other file was ran. It doesn’t solve the problem, but makes it more nicely logged

  2. move packages that introduce dependencies to a 3rd changeLog which is executed after A & B

There may be other solutions based on your needs. Anyone else have suggestions?




what approach should I take for the next use case


Database Engine: Oracle


Let’s say there are two databases A and B, and their corresponding repositories in SVN. A DBA creates dblink L(database link) that connects from A to B, and a developer creates a new package X in database A that calls a procedure in new package Y in database B.


Question 1: How should I save dblink L in repo A? It’s got production environment password on it, should I use a template?

Question 2: The most important question I think, if I create package X in A before package Y in B, compilation won’t be successful because there is no package Y to connect through dblink, how do you manage dependencies between projects (different projects, different databases, different SVN repositories?


Thanks in advance.

one more thing, how do you create dblinks using liquibase? Should I use straight sql tag?

You will need to either use straight tags, or create your own custom extension (liquibase.org/extensions)… There is nothing built into liquibase to handle them.