Add strategy for resolving properties into CQL names

Description

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
class.

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.

Environment

None

Pull Requests

None

Activity

Show:
Alexandre Dutra
October 11, 2016, 8:29 AM

If we go for mapper-level settings like this one, then we could also solve in a similar way.

Aviv Carmi
December 4, 2016, 10:06 AM

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:

  • lowerCamelCase

  • lower-hyphen-case

  • lower_underscore_case

  • UpperCamelCase

  • UPPER_UNDERSCORE_CASE

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.
Any thoughts?

Fixed

Assignee

Unassigned

Reporter

Andy Tolbert

Labels

None

PM Priority

None

Affects versions

None

Fix versions

Pull Request

None

Doc Impact

None

Size

None

External issue ID

None

External issue ID

None

Priority

Minor
Configure