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
7ae7fb1cc0