Custom SQLiteDatabase Implementations

[ChrisLaganiere]

Add a public initializer to DatabaseRow to enable custom SQLiteDatabase implementations

Background

The SQLiteNormalizedCache is nicely structured with protocols so that consumers of the library can implement their own components under the hood if they choose to. There are a couple reasons one might want to do this:

• to use a different SQLite implementation (mentioned as a goal in a comment on the original dependency inversion PR)
• to add custom functionality under the hood, like a TTL policy for rows in the cache (I am trying to follow this path, motivating this PR)

The Problem

All of that is possible! ...almost

The use of SQLiteDatabase protocol makes it easy to implement and inject your own implementation, with one blocking exception. The missing piece is a public initializer for DatabaseRow, a type returned by one of the methods:

apollo-ios-dev/apollo-ios/Sources/ApolloSQLite/SQLiteDatabase.swift

Line 37 in aad10ca

func selectRawRows(forKeys keys: Set<CacheKey>) throws -> [DatabaseRow]

If I as a consumer try to implement the public SQLiteDatabase protocol, I am blocked by this method, because I cannot instantiate DatabaseRow values. The default, automatic memberwise initializer for any Swift struct is internal, meaning that consumers of a library cannot use it, and get an error if trying to instantiate:

The change here, to add an explicit public init to this struct type, is all that is needed to enable custom SQLite implementations, as the original PR from 2021 seems to have intended. This change would allow me to implement the custom TTL policy on my own Apollo cache

Testing

There is no imperative logic change here to test. The best way to unit test this would be to add a full custom SQLiteDatabase implementation to the test suite, which I am happy to do, but seemed like a larger change. Risk here is low, so I skipped doing that for now

Alternatives

I could implement an entire NormalizedCache, possibly copying lots of code already in the repo. That is possible, but it would be much easier to allow flexibility with the utilities already provided by the sdk, by making this small change

[netlify]

👷 Deploy request for apollo-ios-docc pending review.

Visit the deploys page to approve it

Name	Link
🔨 Latest commit	2e8c0ce

[svc-apollo-docs]

✅ Docs preview has no changes

The preview was not built because there were no changes.

Build ID: e1dc8528829c91c4fbc56a0b

[ChrisLaganiere]

by the way, super excited for #615!

[AnthonyMDev]

Thank you for the detailed write-up on the use case here. I'm open to accepting this PR.

[ChrisLaganiere]

Thanks for your help!