Liquibase Community Forum
2010-11-03 15:11:35 UTC
A new topic, 'Operation Mode: SqlFile', has been made on a board you are watching.
You can see it at
http://liquibase.org/forum/index.php?topic=769.new#new
The text of the topic is shown below:
I thought I would share my 'beginner' experiences with liquibase. In particular, I think I'm starting to understand there are different 'operation modes' in how you would leverage Liquibase depending on your environment.
Rather than listing out operation modes, let me summarize my experiences of liquibase in a 'SqlFile' operation mode, and see if people can help provide similar experiences.
---------------------------------------------
Operation Mode: SqlFile
Target Environment/Audience: Environments where database changes are done using native db tools and the deliverable is always change scripts (raw sql scripts, often with native syntax for the target database).
Liquibase Users: Only the 'control' person, or the person responsible for tracking changes to the database.
Limitations: SqlFile operation mode provides no quality controls from liquibase, and changes using the raw script files need to be pre-tested before they are used by liquibase. Rollback feature option still exists, but requires a seperate change script to manually run the rollback feature. Database-specific.
Gains: Creates a 'master' sql change file per promotion, which includes the DATABASECHANGELOG on the deployed databases to have a way to see what changes have been applied. Can also still use the SqlDoc option to generate change documentation from the control files (the db-change.xml files). Reduces the amount of culture/environment change to only the 'control' person.
Description of using this mode:
This mode only focuses on creating 'control files', or db-change.xml files, for each individual change script file. If large change script files are generated, it may be advantageous to breakup the change script file into smaller files, so each change can get its own db-change.xml control file.
The control files use the normal changeSet identifiers, but does require manual tracking of the unique ID's, as well as manual creation of the xml file itself.
Code:
<changeSet id="1" author="dhartford">
<comment>this is a change script for updating a database column</comment>
<sqlFile path="/scmcheckout/project/db/v1.1/table/myupdatetoatable.sql/>
</changeSet>
After each change script has an associated control file, a 'master' control file collects a list of all the control files (following best practices from the liquibase wiki).
Code:
<include file="db.changelog-myupdatetoatable.xml"/>
Then, using the 'master' control file (and assuming consistency in checkouts of your raw sql change scripts), you can create a single master SQL file for normal SQL updates (assuming your environment still requires all raw SQL to run all things):
Code:
liquibase.bat --defaultsFile=targetEnv.properties --changeLogFile=db.master-1.1.xml updateSQL
With this master sql file, you can now promote your environment using a SQL file, but have the DATABASECHANGELOG updated to know what changes have been applied to the database as well as use the SqlDoc option to create change documentation.
Unsubscribe to new topics from this board by clicking here: http://liquibase.org/forum/index.php?action=notifyboard;board=1.0
Regards,
The Liquibase Community Forum Team.
You can see it at
http://liquibase.org/forum/index.php?topic=769.new#new
The text of the topic is shown below:
I thought I would share my 'beginner' experiences with liquibase. In particular, I think I'm starting to understand there are different 'operation modes' in how you would leverage Liquibase depending on your environment.
Rather than listing out operation modes, let me summarize my experiences of liquibase in a 'SqlFile' operation mode, and see if people can help provide similar experiences.
---------------------------------------------
Operation Mode: SqlFile
Target Environment/Audience: Environments where database changes are done using native db tools and the deliverable is always change scripts (raw sql scripts, often with native syntax for the target database).
Liquibase Users: Only the 'control' person, or the person responsible for tracking changes to the database.
Limitations: SqlFile operation mode provides no quality controls from liquibase, and changes using the raw script files need to be pre-tested before they are used by liquibase. Rollback feature option still exists, but requires a seperate change script to manually run the rollback feature. Database-specific.
Gains: Creates a 'master' sql change file per promotion, which includes the DATABASECHANGELOG on the deployed databases to have a way to see what changes have been applied. Can also still use the SqlDoc option to generate change documentation from the control files (the db-change.xml files). Reduces the amount of culture/environment change to only the 'control' person.
Description of using this mode:
This mode only focuses on creating 'control files', or db-change.xml files, for each individual change script file. If large change script files are generated, it may be advantageous to breakup the change script file into smaller files, so each change can get its own db-change.xml control file.
The control files use the normal changeSet identifiers, but does require manual tracking of the unique ID's, as well as manual creation of the xml file itself.
Code:
<changeSet id="1" author="dhartford">
<comment>this is a change script for updating a database column</comment>
<sqlFile path="/scmcheckout/project/db/v1.1/table/myupdatetoatable.sql/>
</changeSet>
After each change script has an associated control file, a 'master' control file collects a list of all the control files (following best practices from the liquibase wiki).
Code:
<include file="db.changelog-myupdatetoatable.xml"/>
Then, using the 'master' control file (and assuming consistency in checkouts of your raw sql change scripts), you can create a single master SQL file for normal SQL updates (assuming your environment still requires all raw SQL to run all things):
Code:
liquibase.bat --defaultsFile=targetEnv.properties --changeLogFile=db.master-1.1.xml updateSQL
With this master sql file, you can now promote your environment using a SQL file, but have the DATABASECHANGELOG updated to know what changes have been applied to the database as well as use the SqlDoc option to create change documentation.
Unsubscribe to new topics from this board by clicking here: http://liquibase.org/forum/index.php?action=notifyboard;board=1.0
Regards,
The Liquibase Community Forum Team.