The Problem Space and Autobase as a Solution

Although Grails provides quite a bit of built-in functionality for managing the database schema, there are holes in the functionality it provides. While its built-in functionality handles creating new schemas, some data type changes, and has some limited support for index creation, it does not handle data migration, it’s awkward for advanced index sets, it doesn’t provide a way to insert or delete rows, and it’s generally just a bit limited. What it does really well, though, is work seamlessly: you make changes to domain objects, and the change is applied inline to the normal development cycle. Autobase fills the holes in Grails built-in functionality while retaining the same inline application, which makes migrations feel a lot more natural part of the flow of development. (For more on this, see The Impetus)

Powered By…

The Autobase plugin is built on top of the Grails plugin and Gant script structures. Under the hood, it uses the Liquibase technology to handle migrations. Vanilla Liquibase is XML-based, but Autobase uses a DSL structure instead. That DSL is a fairly direct mapping of Liquibase’s XML format onto an easier-to-use, Groovy-esque syntax.

Functionality From 50,000 Feet

Developers/DBAs/tinkerers create migration files. Each of these migration files define the way that the database should be changed. On application start-up, the migrations that need to be run are applied to the database, and the system tracks which migrations have been run right in the database. The application of migrations always comes after the built-in schema modifications in Grails, so the full functionality of Grails can be leveraged to speed development and minimize repetition (the all-important DRY principle).

Functionality From 5,000 Feet

Autobase is centered around Liquibase’s idea of a change set. Each change set is made of up of zero or more preconditions and one or more refactorings. Unlike raw Liquibase’s XML format, Autobase uses a much more succinct Groovy Builder to encode change set information. When the Grails application is started (whether from run-app or from a war), after GORM applies its schema changes via hbm2ddl, the builder builds up the change sets, and the system then checks with a table in the database to see if each change set has been previously executed. A change set is run if 1) its preconditions pass, and 2) it has not been previously executed, or if it has changed, or if it specifies that it should always be run. In this way, the system is constantly kept up-to-date.

License

Autobase is licensed under the same license as Grails itself, the Apache 2 license. The license was chosen specifically because it is the license of Grails, so it should be just as amenable for use as Grails is. There are libraries that ship with Autobase (namely, the Liquibase and Liquibase-DSL parts) which are licensed under the LGPL v3.

(Okay, that’s all I got. Only 4 paragraphs, I guess. Head Home and see more.)