CollectionDataProvider.fetchDataFromCache can fail to set the cacheKey

[markkrenek]

When calling CollectionDataProvider.fetchDataFromCache, If there are no objects in the cache matching the cache key, nil is returned for the object array (I might prefer an empty array), but more importantly, the cache key is not set on the provider, so even though you have a delegate listening to the data provider, it will not get notified of subsequent additions to the collection. Here's the sequence I'm doing:

collectionDataProvider = CollectionDataProvider<StoreItemPendingPurchase>()
collectionDataProvider.delegate = self
collectionDataProvider.fetchDataFromCache(withCacheKey: cacheKey)

This returns nil for the error and nil for the object array. And the data provider's cacheKey is still nil. If somewhere else in the app someone sets data on the same cacheKey, I don't find out about it because my data provider's cacheKey is still nil.

Is this expected? If there some way to set the cacheKey independently of using setData() or fetchDataFromCache()?

[plivesey]

This was an issue reported a couple of weeks ago for regular data providers. That change is in master but not yet released (I forgot to do the release :/). But I didn't do it for collections yet. If you take a look at the recent commits, you'll see the changes. The most important thing is to update the consistency manager. Once you do that you can add the behavior to collection data provider with an extension. Anyway, I'm headed to New Mexico for a couple of days, but could work on this when I get back.

…

On Sun, Jan 22, 2017 at 4:38 PM Mark Krenek ***@***.***> wrote: When calling CollectionDataProvider.fetchDataFromCache, If there are no objects in the cache matching the cache key, nil is returned for the object array (I might prefer an empty array), but more importantly, the cache key is not set on the provider, so even though you have a delegate listening to the data provider, it will not get notified of subsequent additions to the collection. Here's the sequence I'm doing: collectionDataProvider = CollectionDataProvider<StoreItemPendingPurchase>() collectionDataProvider.delegate = self collectionDataProvider.fetchDataFromCache(withCacheKey: cacheKey) This returns nil for the error and nil for the object array. And the data provider's cacheKey is still nil. If somewhere else in the app someone sets data on the same cacheKey, I don't find out about it because my data provider's cacheKey is still nil. Is this expected? If there some way to set the cacheKey independently of using setData() or fetchDataFromCache()? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#58>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABMNTRbDBXx6REfjumgjDFBIM8oBi0kYks5rU_aBgaJpZM4LqkSq> .

[plivesey]

Oh, if you want to add an extension as a workaround, it'd be easiest to depend on master instead of the latest.

…

On Mon, Jan 23, 2017 at 8:53 AM Peter Livesey ***@***.***> wrote: This was an issue reported a couple of weeks ago for regular data providers. That change is in master but not yet released (I forgot to do the release :/). But I didn't do it for collections yet. If you take a look at the recent commits, you'll see the changes. The most important thing is to update the consistency manager. Once you do that you can add the behavior to collection data provider with an extension. Anyway, I'm headed to New Mexico for a couple of days, but could work on this when I get back. On Sun, Jan 22, 2017 at 4:38 PM Mark Krenek ***@***.***> wrote: When calling CollectionDataProvider.fetchDataFromCache, If there are no objects in the cache matching the cache key, nil is returned for the object array (I might prefer an empty array), but more importantly, the cache key is not set on the provider, so even though you have a delegate listening to the data provider, it will not get notified of subsequent additions to the collection. Here's the sequence I'm doing: collectionDataProvider = CollectionDataProvider<StoreItemPendingPurchase>() collectionDataProvider.delegate = self collectionDataProvider.fetchDataFromCache(withCacheKey: cacheKey) This returns nil for the error and nil for the object array. And the data provider's cacheKey is still nil. If somewhere else in the app someone sets data on the same cacheKey, I don't find out about it because my data provider's cacheKey is still nil. Is this expected? If there some way to set the cacheKey independently of using setData() or fetchDataFromCache()? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#58>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABMNTRbDBXx6REfjumgjDFBIM8oBi0kYks5rU_aBgaJpZM4LqkSq> .

[markkrenek]

You're talking about listenToModelIdentifier I suppose. Excellent. My work-around was to simply call setData([], cacheKey: cacheKey) when there was a cache miss. That manages to get the cacheKey assigned. I assume it's kosher.

[plivesey]

That seems like a great workaround for now. I'll add the other API soon.

…

On Mon, Jan 23, 2017 at 4:07 PM Mark Krenek ***@***.***> wrote: You're talking about listenToModelIdentifier I suppose. Excellent. My work-around was to simply call setData([], cacheKey: cacheKey) when there was a cache miss. That manages to get the cacheKey assigned. I assume it's kosher. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#58 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABMNTbnWzhoZ0_IjWVI-bRXL6djSJMeZks5rVUC6gaJpZM4LqkSq> .

[plivesey]

Hmmmm...so I looked into this more, and it's a bit more complicated than I thought. After adding this feature, a bunch of tests started failing.

The shared collection stuff gets much more complicated. If you end up missing the cache by error (like a disk fail), then you could end up setting all the shared collections to []. Gave it a quick shot today, and will think about this more...

[mwaterfall]

I've just experienced this issue. Any progress @plivesey? At the moment I've just resorted to my cache delegate always returning a [] if a collection cache miss occurs. I can justify this as the collection data provider doesn't work with optional arrays (collectionDataProvider.data is not an optional).

[plivesey]

No progress...sorry, been busy with a new job. I may have some time to look over the weekend.

The main problem is, I'm afraid of doing this in a general way, because if you get some I/O failure, then we set this collection as the cache key. Then, next time we read, we'll treat this value as the correct value (even though we should reread from the cache). I'm guessing this doesn't matter to you but seems like we need to keep track of this in a better way.