commit 7ae7fb1cc0984032016fe6ce1fa49b9735a98ed8
author Dave Borowitz <dborowitz@google.com> Sat Apr 21 11:25:41 2018 -0400
committer Dave Borowitz <dborowitz@google.com> Fri Apr 27 12:25:45 2018 -0400
tree c25ad0d823c302f1d386fe7689d386a8764daa19
parent 9bb008bbebcf5bf00d525a7272e2caf62cb4714a

Allow alternative serialization strategies for persistent caches

We want to have finer control over when persistent cache data is
invalidated due to the stored format changing. Depending on the Java
serialVersionUID, as we have done in the past, has two significant
downsides:
 * Adding new fields which can have a reasonable default, or removing
   old obsolete fields, always requires bumping the serialVersionUID and
   thus flushing the cache. With an alternative serialization strategy
   like protobuf, we can continue reading old entries in some cases.
 * Trivial refactorings which do not change the data semantics, such as
   renaming classes or fields, also flush the cache.

Both of these types of cache flushes have happened to PatchListCache in
the past year. Other serialization strategies such as protocol buffers
allows us to avoid unnecessary cache invalidations.

This change introduces a new interface CacheSerializer, which is used to
convert arbitrary objects to and from a simple byte array. This is
backwards compatible with the existing OTHER column type in H2, which is
implemented as a byte array, and accepts arbitrary data written with
PreparedStatement#setBytes and similar, not just #setObject.

Each SqlStore instance has a pair of CacheSerializers for the key and
value types. However, note that when the key type is String, the
existing StringKeyTypeImpl does *not* use a CacheSerializer for
serialization, since unlike the OTHER column type, the VARCHAR type
cannot just take a simple byte array. In the long term, it may make
sense to drop the KeyType class entirely, and instead use the
CacheSerializer to convert to bytes even for strings.

Change-Id: I150c1c8b8cd35b98c1a0792572d2e1ded4172774