From the cassandra-user mailing list: http://mail-archives.apache.org/mod_mbox/cassandra-user/201610.mbox/%3cCAKiMtbe1vYc=w17+-j25yG6vdh15hjG9vNR=PFSn6=Ojkny0Fw@mail.gmail.com%3e
In working with Jackson, it has a NamingStrategy which lets you
automatically map snake_case fields in json to camelCase fields on the Java
Last time I worked w/ Cassandra, I didn't find anything like that, and had
to define an @Column annotation for each field.
This seems like a good idea because a common naming convention for columns in CQL is to use all lowercase and underscores, while the common naming convention for java is to camel case.
Jackson Databind's PropertyNamingStrategy to define how pojo fields are mapped to json properties. A similar approach for the driver mapper could be a nice convenience mechanism.
If we go for mapper-level settings like this one, then we could also solve in a similar way.
OK so I started working on that on top of the JAVA-1310 pull request. The way i see it designed is to have a NamingStrategy object in the mapper configuration - consists of two properties:
inputNamingConvention - the naming convention of the java fields/getters (which defaults to camelCase)
outputNamingConvention - the naming convention of the cassandra columns (which defaults to snake_case)
This way, not only we can transform to, say, lower-case or to snake_case, we can also say, expect the bean fields to be in snake case (e.g. user_id), and write out in camel case (e.g. userId).
So, to start off, Jackson's PropertyNamingStrategy is not quite what we need since it only transforms from snakeCase.
So apparently, Guava has just that, a method of translating from a selected format to a selected format, featuring:
But, it has two problems for us. Since Guava implemented those as enum values, we cannot extend them, meaning we cannot provide the consumer with an interface to override this behavior if he doesn't use one of the above.
The second issues is with separation of abbreviations - when translating from camelCase to snake_case (which is our default), Guava will translate the value "myUDTObject" (for instance) to "my_u_d_t_object", which we would probably want to be "my_udt_object" by default.
In order to solve these two issues we can look for another open source solution (if anyone seen such) or try implementing ourselves.