Make annotations optional for object mapping (use smart defaults via reflection)

[ikester]

How about making the annotations optional and use reflection to pick up the field names as default column names? I believe that's how some of the newer frameworks do it (e.g. Play).

For example:
class Foo(id: Long, name: String, email: String, dob: Date)

The ColumnFamily would be "Foo", the key would be the value of "id", "name" and "email" would be StandardColumn names with string values and "dob" would be a StandardColumn name with it's value correctly serialized from a Date object.

[shorrockin]

I really like this suggestion, as I'm not a huge fan of annotations but it seemed like the most obvious approach at the time. Let me brainstorm a bit on this and see what I can do.

Any thoughts on what the defaults would be for mapping a super column family?

[ikester]

Not initially. I guess it would depend on the relationship/array/set we're trying to model. If it was a one-to-many the super column names could be TimeUUIDs. But the current consensus seems to be that data modeling for Cassandra (as for most non-relational data stores) should be done based on how the data will be accessed (as opposed to how it's convenient for storage).

So my general suggestion would be to provide some basic building blocks to help with the mapping without imposing a particular schema. That's what I liked about your initial approach, it does the tedious, boilerplate work of mapping columns to objects without constraining the developer.

An annotation may be the most convenient option for these cases. If I think of something concrete I'll let you know.

[ikester]

oops, accidentally closed it.

[shorrockin]

Great - Thanks again for the suggestion and feedback. I'm going to start iterating on this tonight as I my team (who is largely guys new to Scala/Cassandra) would really benefit from it come Monday morning.

[shorrockin]

After some investigation it appears that this may have to wait until I integrate Scala 2.8. The ability to do reflection on case classes (which is how I would like to see this modeled) is very difficult if not impossible in 2.7. The changes introduced in 2.8 should make it more easy to figure field name mapping.

The alternative of course is to force that mapped classes are not case classes, have a zero-arg constructor (essentially a java bean) but i would prefer not to take this approach.