Details of the latest changes in dropwizard-cassandra , including support for Cassandra 2.1 and a new versioning scheme

In previous posts , I described the dropwizard-cassandra library and how it can make life easier when interacting with Cassandra from a Dropwizard app. With the recent release of Cassandra 2.1, the library needed a small upgrade to support those changes.

For the most part, this was a simple upgrade of the DataStax Cassandra Driver from version 2.0.x to 2.1.x - but it's worth pointing out how this might affect you and what new features you can use when you upgrade.

Version Changes

I've at how to version dropwizard-cassandra to target multiple versions of Dropwizard. This is particularly in preparation for Dropwizard 0.8.0, as my library will need to work against more than just the most recent release (not everyone can upgrade straight away, or even wants to).

In addition, the same applies to the Cassandra driver. Now that Cassandra 2.1 has been released, DataStax have released a new version of the driver to take advantage of new features and support any changes in the binary protocol since v2.0. While this is great, it should not force users of prior versions of Cassandra to upgrade their driver. Some might prefer to allow more time for the new driver to be battle-tested by others before upgrading their own apps.

For these reasons (and others), users will want dropwizard-cassandra to work against different versions of both Dropwizard and Cassandra; so I've decided to define and release a matrix of supported platforms. This ensures that multiple combinations of Dropwizard and Cassandra driver will work, and will not force users to upgrade either Dropwizard or their Cassandra driver unless they want to.

To support this, I've decided to include both the Dropwizard ( dw ) version and the Cassandra ( cs ) Driver version in the version of dropwizard-cassandra using the format: ${lib.version}-${dw.version}-${cs.version} . This is not practical at the patch level, so it only applies to the minor version. Unfortunately this makes for a more complicated versioning scheme, but it achieves the goal of version independence from the major dependencies.

So as it stands, the latest released versions are 1.0-dw0.7-cs2.0 (supporting Dropwizard 0.7.x and Cassandra Driver 2.0.x) and 1.0-dw0.7-cs2.1 (supporting Dropwizard 0.7.x and Cassandra Driver 2.1.x).

I'm very happy to accept feedback on this going forward. I've looked into how this is done in a number of other libraries and have not found any particularly 'pretty' solutions, but am fully open to suggestion.

For the sake of clarity, the ${lib.version} signifies changes in the library itself. This may include new features or bug fixes that do not correspond to a change in either Dropwizard or the Cassandra driver.

Version Compatibility

For those that do want to upgrade to the newer version of the Cassandra driver, it's worth noting that there is one aspect where this might require changes in your configuration: the protocol version.

With the latest driver, protocol version is no longer an int defaulting to -1 but is now a ProtocolVersion enum defaulting to null (which allows the driver to negotiate with the Cassandra cluster which protocol version to use). Note that this is only considered a breaking change if you've explicitly configured the protocolVersion configuration option in your app. If you're relying on the default value, it'll work as before.

Changes in the Driver

I'll leave it to you to see the full list of changes in the driver, but will just point out a few highlights here.

Firstly, a new Object Mapping API has been made available (via a separate dependency). This allows you to annotate objects for persistence in Cassandra and get a Mapper<T> from a MappingManager to persist or retrieve data. You can think of it as a kind of JPA for Cassandra. Whether you like that kind of thing or not is up to you.

There's also support for some of the new features in Cassandra 2.1 like UDTs and TupleTypes .


23 October 2014