Cache issue: overlay image changes but URL does not
Hello,
I am doing something similar to the coffee mug example you have here.
The problem I am having is that the URL for the complete image (base + overlay) stays the same but the overlay image is being constantly changed by the user. That causes a cache issue since after the first time the user has chosen the overlay image - it will always be the same (unless it will be uploaded with a different id which is an unwanted solution). Is there anyway to provide the version of the overlay image or any other way around it?
Thanks.
-
Hey,
Thanks for reaching out.
You're right. Overwriting an overlay image will not affect existing derived resources in your account.
A possible solution is to use the `underlay` parameter instead. It means that the image you change often will be the main image and the background (i.e., the coffee mug in our example) will be set as an underlay of that image.
For example,
That way, when overwriting and invalidating the image, all derived copied will be deleted as well.
Hope this help, Let me know if you have any further questions.
0 -
Thank you Maor for your response.
I was wondering - Is there any way to invalidate or break the cache in such a case?
Is there any way to control caching?
Thanks.
0 -
Hi,
In the case you specified, you need to re-upload (overwrite) and invalidate the *main* image. Doing so will also automatically delete and invalidate the derived copy.
That being said, switching the approach to `underlay` will do the same when you overwrite the main image (goes well with your use-case).
0 -
I'm having a similar issue here. I think it is good if there is a way to invalidate the overlay image. Seems like my corrupted image is permanently stuck.
0 -
Hi @CloudClefs Vendor,
In order for the new overlay image to be reflected, you actually need to re-generate the derived resource. Did you do that? If you did and still see an issue, please share a couple of example URLs via support@cloudinary.com and will be glad to help further.
0
Post is closed for comments.
Comments
5 comments