Thanks. I think the style storehaus is using stores is different from what i intitially wanted to get from dynamic composites and in the end i mixed it up, sorry for that. i tried to use a dynamic composite store. This has the advantage that - in theory - the whole store is not type safe in the sense of storehaus, but in the sense of cassandra, as the serializers are identified in the column family definition and a hint is getting written for every part of the key and the column what serializer to use. But as i made the serializers a parameter to the constructor they are somehow fixed anyways. @ianoc @johnynek So i'd like to hear your opinions on how to proceed. My personal favourite would be to split this up into to stores: 
   * one _non-dynamic_ composite store with fixed types (baked into the column family definition which offers the advantage of defining secondary indexes), a case class to hold the types and a fixed row layout
   * one with a map for type->serializers, such that you can store any of the types in the map in different order on any put or get operation (need to test that if this really fully works, though, just an idea) but imho the types cannot be fixed for that but must be identified through intospection and used along with the map