generateChangeLog command

The generateChangeLog command creates a changelog file that has a sequence of changesets which describe how to re-create the current state of the database.

Uses

The generateChangeLog command is typically used when you want to capture the current state of a database, then apply those changes to any number of databases. This is typically only done when a project has an existing database, but hasn't used Liquibase before. See How to set up Liquibase with an Existing Project and Multiple Environments for more details.

Note: When using the update command to apply the changes in the changelog, Liquibase will not create a new database or schema. You must create them before applying the changelog to it.

Running the generateChangeLog command

To generate a changelog:

1. Configure the liquibase.properties file to include your driver, classpath, and URL for the database you want to capture.

Note: For more information on how to configure your liquibase.properties file, see the Creating and configuring a liquibase.properties file topic. Instead of using a liquibase.properties file, you can also pass the necessary information on the command line.

2. Open your CLI and run the following command:

liquibase --changeLogFile=dbchangelog.xml generateChangeLog

Note: If you want to create an SQL changelog file, add your database type name when specifying the changelog file: liquibase --changeLogFile=mychangelog.oracle.sql generateChangeLog. Replace .oracle.sql with your database type. When in doubt about your database type name, check Supported Databases.

generateChangeLog global attributes

Attribute	Definition	Requirement
--changeLogFile	Specifies the root changelog.	Required
--url	Specifies the JDBC database connection URL.	Required
--username	Specifies the database username.	Required
--password	Specifies the database password.	Required
--liquibaseProLicenseKey	Specifies your Liquibase Pro license key.	Optional

Note: The username and password attributes are not required for connections and systems which use alternate means of authentication.

generateChangeLog command attributes

Attribute	Definition	Requirement
--defaultCatalogName=<name>	Specifies the default database catalog to use.	Optional
--defaultSchemaName=<name>	Specifies the default database schema to use.	Optional
--schemas=<name1, name2>	Specifies database schemas you want to include.	Optional
--outputSchemaAs=<name1,name2>	Uses the names as schemaName instead of the real names on the generateChangeLog command.	Optional
--includeCatalog=[boolean]	Includes the catalog in a generated changesets if the value is true. The default value is false.	Optional
--includeSchema=[boolean]	Includes the schema in a generated changesets if the value is true. The default value is false.	Optional
--includeTablespace=[boolean]	Includes the tablespace of tables and indexes in a generated changesets if the value is true. The default value is false.	Optional *
--dataOutputDirectory=DIR	Sends the data output as a CSV file in the given directory.	Optional
--diffTypes	Includes a list of diff types in a changelog file expressed as a comma-separated list (without spaces) from: catalog,tables,functions,views,columns,indexes,foreignkeys,primarykeys, uniqueconstraints,data,storedprocedure,triggers,sequences.	Optional **

* --includeTablespace only captures the tablespace if it was specified in the create table statement.

** If the --diffTypes value is null, then the default types will be: tables, views, columns, indexes, foreignkeys, primarykeys, uniqueconstraints.

Output

The generateChangeLog command generates a changelog that contains all your Objects (represented as changesets) and places the file in the same directory where the command was ran.

The extension you provide determines the format of the changelog, so if you specify the filename as changelog.xml, you will get an XML formatted changelog. However, if you specify the filename as changelog.yaml, changelog.json, or changelog.postgresql.sql, you will get changelogs formatted in YAML, JSON, or SQL respectively.

Additional functionality with Liquibase Pro

While Liquibase Community stores all changesets in a changelog, Liquibase Pro creates a directory called Objects and places the directory at the same level as your changelog. The Objects directory contains a subdirectory for each of the following stored logic types:

• package
• packagebody
• function
• stored procedure
• trigger
• view

Note: Not all database platforms support all stored logic types that are listed.

If your database contains stored logic objects, you may have issues attempting to run the generateChangeLog command more than once, even with a new changelog name, because the stored logic files already exist in the Objects directory.

To generate a newer version of the changelog file with stored logic objects based on the current database state, you need to delete, rename, or move the Objects directory that was created by running the generateChangeLog command previously. Then, you can run the generateChangeLog command again.

Note: If there is a pre-existing Objects directory that is not related to Liquibase, you need to delete, rename, or move it to run the generateChangeLog command.

If you want to track the history of stored logic objects, use the diffChangeLog command. The diffChangeLog command structures stored logic files into timestamped directories every time you run the command.