Why Achilles

Achilles development has started at the end of 2012.

At that time, there were already several frameworks to do object mapping with Cassandra

1. Hector Object Mapper
2. Kundera
3. Easy Cassandra
4. FireBrand
5. PlayORM
6. Asytanax
7. ...

At that time, most of them have interesting features like fluent API, simple mapping etc. but none of them offers a comprehensive feature sets necessary for a really productive development with Cassandra. Furthermore, advanced mapping (with composite and later with clustering primary key) were not available. No support for counters, no runtime settings for TTL, timestamp or consistency level.

I then decided to start a writing my own tool, Achilles.

The name itself was chosen quite lamely, I wanted a name related with the Greek mythology and since all characters related to Cassandra were chosen (Kundera, Hector, Helenus to name the few), I decided to go with Achilles but there is really no relationship with Cassandra, at least with regards to the Greek mythology.

So please don't ask me what is the Achilles heel ?, I can't really tell.

The first generation (Achilles 1.x) were implemented using Hector. It was a great effort, but the implementation and design is somehow awkward. It was very hard to rely just on Hector API to build up an object mapper and PersistenceManager. The code base was quite huge.

The second generation (Achilles 2.x) adds support for CQL relying on the brand new Java Driver from Datastax. Coding was much easier, a lot of new features have been added (advanced mapping for compound primary key, clustered entity, batch mode ...)

The third generation (Achilles 3.x) drops the Thrift implementation to move on with full CQL and offers support for all new features in Cassandra 2.x

The current generation (Achilles 4.x) is a complete rewrite, it uses compile-time code generation to offer greater type-safety as well as a fluent DSL query builder.