Group items tagged

t just works - Migrate from any version (incl. an empty database) to the latest version of the schema Automatic migration on startup - Ship migrations together with the application and run them automatically on startup Convention Over Configuration - Classpath Scanning to automatically discover Sql and Java migrations Plain Old Sql - SQL scripts for regular migrations (incl. placeholder replacement). No proprietary XML formats, no lock-in. No limits - Java classes for advanced migrations Highly reliable - Safe for cluster environments (Multiple machines can migrate in parallel) Maven support - Maven plugin for migrating manually Fail fast - Inconsistent database or failed migration prevents app from starting. Schema Clean - Drop all tables, views, triggers, ... from a schema without dropping the schema itself

DdlUtils is a small, easy-to-use component for working with Database Definition (DDL) files. These are XML files that contain the definition of a database schema, e.g. tables and columns. These files can be fed into DdlUtils via its Ant task or programmatically in order to create the corresponding database or alter it so that it corresponds to the DDL. Likewise, DdlUtils can generate a DDL file for an existing database. DdlUtils uses the Turbine XML format, which is shared by Torque and OJB. This format expresses the database schema in a database-independent way by using JDBC datatypes instead of raw SQL datatypes which are inherently database specific. An example of such a file is:

There is no migration system in vanilla grails (although possibly in Grails 2.0 …. ?) but there do exist several plugins that provide  some migration functionality. As of this post I am aware of three: dbMigrate, Liquibase, and Autobase. Of these, I prefer Liquibase and cannot recommend it enough. While it uses XML to describe its changesets it is a mature open-source Java project that works flawlessly (and has some excellent documentation). I did not have much luck using DbMigrate and Autobase when including in an existing project… which is a shame as Autobase (which is built on Liquibase) uses a nice DSL syntax to build the migrations.

"The past year I've been learning a lot of Scala and I'm currently working on a new project using Scala. I use LiquiBase, which is a database-independent library for tracking, managing and applying database changes. I'm also using the simple-build-tool (SBT) for my project. So I've put together a little SBT plug-in for running LiquiBase maintenance commands (update, rollback, …) from within SBT. For example, whenever I want to apply new database changes with LiquiBase I can now simply run sbt liquibase-update which sets up a new instance of LiquiBase and executes the LiquiBase update command which migrates my database to the latest version. At the moment the plug-in supports the following commands: liquibase-update, liquibase-drop, liquibase-tag, liquibase-rollback and liquibase-validate. What are the benefits of using the plug-in and not just the LiquiBase CLI? * no download/install of LiquiBase * classpath handled by SBT * no need to provide a big list of parameters or writing shell scripts The plug-in is called liquibase-sbt-plugin and you can find it here on GitHub. Feel free to use it or fork it and suggest changes. I'm still relatively new to Scala and especially SBT so any remarks are very welcome."

The Compact Namespace and Node Type Definition (CND) notation provides a compact standardized syntax for defining node types and making namespace declarations. The notation is intended both for documentation and for programmatically registering node types (if you are unfamiliar with JCR node types, you may want to read the general Node Types section first).