💧 first drop for a SQLite backend that stores when each field was last updated

[martinbonnin]

See #3566

First drop for a SQLite backend that stores when each field was last updated. It introduces a new SQLite table that stores Records in a binary format that also holds the last updated timestamp.

This allows to throw a cache miss when a given field is older that a configured max-age

    val client = ApolloClient.Builder()
        .normalizedCache(
            normalizedCacheFactory(),
            TypePolicyCacheKeyGenerator,
            MaxAgeCacheResolver(10) // Allow 10s for the max Age
        )
        .serverUrl("https://...")
        .build()

    val records = query.normalize(data, CustomScalarAdapters.Empty, TypePolicyCacheKeyGenerator).values

    client.apolloStore.accessCache {
      // store records 11s in the past
      it.merge(records, cacheHeaders(currentTimeMillis()/1000 - 11))
    }

    try {
      client.query(GetUserQuery()).fetchPolicy(FetchPolicy.CacheOnly).execute()
      fail("An exception was expected")
    } catch (e: CacheMissException) {
      assertTrue(e.age != null) // Age will be 11s
    }

Next steps:

• add more tests
• make the maxAge configurable per-type/per-field programmatically
• make the maxAge configurable per-type/per-field declaratively
• add benchmarks

[netlify]

✅ Deploy Preview for apollo-android-docs canceled.

Name	Link
🔨 Latest commit	122147a
🔍 Latest deploy log	https://app.netlify.com/sites/apollo-android-docs/deploys/62853e63a839d400090d01ab

[BoD]

On thing that I'm not entirely sure I understand: the date stored along with fields - with the MaxAgeCacheResolver they're meant to represent the time at which they were received, right? But with a different Resolver, they could also represent an expiration date in the future (whose value could come from the server), right? So it is a generic date - its usage can adapt to needs?

[martinbonnin]

One thing that I'm not entirely sure I understand: the date stored along with fields - with the MaxAgeCacheResolver they're meant to represent the time at which they were received, right? But with a different Resolver, they could also represent an expiration date in the future (whose value could come from the server), right? So it is a generic date - its usage can adapt to needs?

Excellent question. At the moment it's mostly the receive time. We could store the expiration time too I guess. It wouldn't be too hard I think. Something I want to improve is to make sure a given database is always open with the same assumption (blob vs json, date vs expire). I'll suggest something

[martinbonnin]

Also closes #3758