iOS Cache Serialisation to use custom scalar types

[qalvapps]

We use custom scalar type's in our schema which Apollo uses successfully to parse the network response, but it seems when apollo persists this data using the SqlNormalizedCache, the data is stored 'as is' and doesn't use the custom scalar types for serialisation. Apollo reading from cache then ultimately fails.
Any way to get serialisation to use custom scalar types ?

This is similar to issue with Android, which had issue raised last week which subsequently received a PR :
issue: apollographql/apollo-kotlin#1001
PR: apollographql/apollo-kotlin#1010

[liamjdouglas]

Here maybe? #262

[qalvapps]

thanks Liam, thats not quite the issue. I have custom scalars working when parsing network response as is described in your linked issue. The issue is that Apollo doesn't use custom scalars when serialising persisted data from SqlNormalizedCache

[qalvapps]

wonder if theres an answer for this ongoing issue yet ?

[mkv27]

Temporally,
1- You can create a custom store #328
2- Then create custom SQLiteNormalizedCache based class and review:

apollo-ios/Sources/ApolloSQLite/SQLiteNormalizedCache.swift

Line 137 in 4f35f04

private static func deserialize(fieldJSONValue: JSONValue) throws -> Record.Value {

[niraj1991]

Hello @qalvapps and @liamjdouglas

I have same issue in version 0.10.1.

When I am using custom scalar types at that time Watcher is not calling while update the Cache. Do you have any solution?

Thanks

[designatednerd]

There's definitely some gooberyness going on with this, I'll have to do some excavating to figure out what's going on.

[ppowers10]

I have been having the same issue as @qalvapps. His statement: I have custom scalars working when parsing network response as is described in your linked issue. The issue is that Apollo doesn't use custom scalars when serializing persisted data from SqlNormalizedCache seems to be the same thing I'm facing.

A couple things to note:

• We are using SqlNormalizedCache so that we can gain extended offline support for our network requests.
• We are using --passthroughCustomScalars
• When we fetch the graphql query, it parses properly against our local custom scalar type definition to ensure it is JSONDecodable.
• We are using SqlNormalizedCache and we see the ApolloClient.swift fail to fetch from cache at the client.store.load(query: query) { result in ... }. The error is returning as GraphQLResultError Apollo.JSONDecodingError.missingValue against my custom scalar type.
• If I switch over to an .InMemoryNormalizedCache() caching mode, it loads properly from cache.

[designatednerd]

OK thank you very much for the detailed info - I'll see what I can do about this when I get back from moving.

[ppowers10]

@designatednerd I think we found the underlying issue. Some of our Queries variables contain .. One of the values is the version of the app which the graphql server wants to know. In doing this, the shouldComputeCachePath check will fetch the variables and create a string for the cacheKey. The issue is that you have other logic in the framework which will strip the . at certain points due to your SQLite record management. So in the end, adding .replacingOccurrences(of: ".", with: "-") fixed the issue. The section of code in GraphQLExecutor now looks like this:

if shouldComputeCachePath { let cacheKey = try firstField.cacheKey(with: info.variables).replacingOccurrences(of: ".", with: "-") info.cacheKeyForField = cacheKey info.cachePath.append(cacheKey) }

There still seems to be an issue in SQLiteNormalizedCache related to guard let reference = dictionary[serializedReferenceKey] as? String else {...}. I need to return return fieldJSONValue if that guard fails, otherwise all my queries fail.

[designatednerd]

Oof, yeah, that would definitely break the hell out of trying to parse key paths. Thanks for the info!

[designatednerd]

This issue should be fixed by #1144, which shipped with 0.26.0. If you're still having issues around this after upgrading, please open a new issue with which version you're using and we'll hunt it down from there. Thank you!