Use Liquidbase to create objects in empty database

General Discussion
1

Hi,


I am trying to use Liquibase to create objects in empty database.

Since we have quite a lot of objects I decided to split them into separate XML files based on

purpose of objects (security.xml, services.xml, datasources.xml etc).


My idea is that during the development the changes will always be written into appropriate XML file.


In each of these files I have changesets to create tables, add PK, add FK - the usual I think.


Now, when first XML starts to be executed, it will create tables and tries to add FK to tables that has not

been created yet, because they reside in another XML that has not been processed yet.


Is there any way how to solve this and still keep my setup ?


My idea would be to use to execute changeset that would create missing table before adding the FK.

Or maybe there is a way how to specify that one changeset has predecessors ?


Im really new to Liquibase and maybe I do it completely wrong :slight_smile:


Thanks for any suggestions,

Zbynek

UPDATE:

Since I havent got any reponses, I have dealt with this situation by using two different files
security-create.xml & security-update.xml (and many others in this manner).
The '-create' guy contains only SQL CREATE and '-update' contains all PK, FK, INDEXES etc.

Just making sure the ALL '-create' files are executed before any '-update' using 
and putting them into different folders.

Just in case anyone could make use of this...
2

Sorry you hadn’t gotten a response.

The thing to remember about organizing your changesets is that in the end they get flattened into a list and ran from top to button, and order can matter. Just like it is usually best to add changeSets to the end of a changelog, you normally only want to be adding to the “last” nested changelog in the flattened list. 

It can work to have independent changelogs by feature or by component, but only if the database objects in those files are completely independent. If there is overlap and references between them, it will cause problems down the road.

Normally my suggestion is to break up changelogs by release. Have a 1.1.xml, 1.2.xml, 1.3.xml file etc. That generally gives manageable sized files and automatically has you working on the end of the flattened list. If you end up going back to a fixpack on an earlier version, adding to the earlier changelog usually works just fine because since the change won’t depend on anything in later versions.

Nathan