(In reply to Misha H. Ali from comment #13)
> Additionally, one of the requirement is:
> 
> - We should also document how the compatibility mode format could be
> leveraged to preserve values of an entry when writing with a (custom) cache
> store, so that data is not stored as a binary blob and can be processed
> meaningfully by HBase, Cassandra, etc.
> 
> We don't have any information on how to do this, so I'll wait and check with
> mircea when he returns from PTO. Or perhaps if Tristan knows, he can fill in
> the blanks.

(In reply to Tristan Tarrant from comment #14)
> Acked the Pad.
> When mmarkus mentions "provided store",  he means one of the stores we
> package (singlefile, jdbc, remote, rest, leveldb)
> Compatibility mode does not actually mandate any format, it is merely a
> framework for automatically converting entries between the formats expected
> by the different access modes (embeddded, hotrod, etc).
> A custom cache store has access to the "raw" key/values in the cache and
> therefore can be programmed to understand those values and write them to the
> persistent backend of choice using an appropriate schema. Examples:
> - if the value is a POJO, a custom cachestore can obtain data from it
> (provided it knows its type)
> - if the value is annotated with JPA annotations, a custom cachestore could
> use JPA itself to write data to the persistent store in a schema-aware
> fashion
> - if the value is structured text (e.g. XML, JSON, etc), a cachestore could
> parse it to extract the actual items of data.