Just as application code evolves and changes so do database schemas. If you are building an application and intend to support upgrading from one version to another, then managing schema changes is essential. If you are lucky, you might be able to get by with running some simple upgrade scripts to bring the schema up to date with the new version. This likely will not work however if you support multiple upgrade paths. For example, suppose we have versions 1 and 2, and are introducing version 3 of an application. We want to allow upgrading to version 3 from either 1 or 2 in addition to upgrading from 1 to 2.
You could add schema upgrade logic to application code, but that is often a less that ideal solution as it convolutes the code base. Fortunately, there are tool for managing schema changes like Liquibase, Flyway, and Active Record for Ruby on Rails applications. These tools however, are designed specifically for relational databases. I previously spent time trying to patch Liquibase to support Cassandra but found that it was not a good fit. Cassalog is designed solely for use with Cassandra, not for any other database systems.
Cassalog is written in Groovy. There are several reasons for this. First, Groovy offers great interoperability with Java, making it usable and accessible to application running on the JVM. Groovy’s dynamic and meta programming features make it easy to write domain specific languages. Groovy has multi-line strings and string interpolation out of the box, both of which can be really useful for writing schema change scripts. Lastly, with Cassalog schema changes are not written in XML or JSON. Instead they are written as Groovy scripts giving you the full power and flexibility of Groovy.
