Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Passing non-default ImageProcessor to ImagePrefetcher will always cause cache miss #589

Closed
Killectro opened this issue Feb 9, 2017 · 2 comments

Comments

@Killectro
Copy link
Contributor

When you pass an ImageProcessor to ImagePrefetcher it will check to see if it exists in the cache like this:

let alreadyInCache = manager.cache.isImageCached(forKey: resource.cacheKey).cached

If that returns false it will continue on, download the image, process it, and store it like this:

targetCache.store(image,
                  original: originalData,
                  forKey: key,
                  processorIdentifier:options.processor.identifier,
                  cacheSerializer: options.cacheSerializer,
                  toDisk: !options.cacheMemoryOnly,
                  completionHandler: nil)

Both cache keys are calculated using the same method:

let computedKey = key.computedKey(with: identifier)

but you might notice, that above when calling the isImageCached(forKey:processorIdentifier:) method, ImagePrefetcher doesn't pass the processorIdentifier: parameter. This means that if the URL is example.com, ImagePrefetcher is checking (the md5 hash of) example.com to see whether there is a cached version, but when it goes to download and store the image, it is storing it at example.com@<processor_name>. This means that the ImageProcessor will never have a cache hit if you pass anything other than DefaultImageProcessor as an option.

This can be remedied by simply passing the processorIdentifier: parameter as such:

let alreadyInCache = manager.cache.isImageCached(forKey: resource.cacheKey, processorIdentifier: optionsInfo.processor.identifier).cached

I will open a PR by EOD today that fixes this bug.

@onevcat
Copy link
Owner

onevcat commented Feb 10, 2017

You are definitely correct on this! Thank you!

@onevcat
Copy link
Owner

onevcat commented Feb 11, 2017

Should be fixed in version 3.4.0.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants