This project has moved and is read-only. For the latest updates, please go here.

Cache Not Maintained By Create Function

Topics: Developer Forum
Apr 16, 2011 at 4:14 AM

Hi All,

I have some code that basically does;

GetPhotosets -> Does Photoset Exist ? { No - Create Photoset } -> Add photo to photoset

This code is run in a loop over multiple images. What I discovered is that after the call to create a photoset, the result of any subsequent calls to PhotosetsGetList doesn't include the newly added set(s) unless caching is disabled.

It seems the PhotosetsCreate call doesn't update the internal cache when it successfully adds a new set. Obviously I can track the sets myself, but it seems like a flaw that the cache is accurately maintained. I suspect this might be the with other methods too.

Anyone know if there is a better way around this than disabling the cache or creating my own cache of known sets ?

Apr 18, 2011 at 1:38 PM

You can either temporarily disable the cache before the call to GetPhotosets, or you can call Flickr.Flush and pass in Flickr.LastRequest url to flush the cache of the previous call to GetPhotosets.


Apr 18, 2011 at 8:53 PM

Hi Sam,

Thanks for the response, I appreciate it.

Since the CacheDisabled property seems to be static, and I presume therefore affects ALL instances of the Flickr class, I think I prefer using the Flush method... thanks for pointing that out.

Having said that, I bleieve doing so will still cause the next PhotosetsGetList call to go back to Flickr, increasing the QPS on the Flickr API for my app and probably being slower than accessing the cache. That seems unnecessary since FlickrNet knows it just successfully added a photo to that set. Any chance changing this might be considered for a future version ?

My other option is to build my own cache, at least for items I know I've added, but FlickrNet is doing such as great job in the first place that seems a shame.

Thanks again.



Apr 21, 2011 at 9:05 PM

Sounds far too complicated and time consuming to actually do the work to search the cache for anything that might need modifying and then try to 'insert' fake XML into the cached response. I suspect it would be quicker for a system to simply query Flickr again, and certainly easier for me.

If you are getting a list of photosets, and then creating new ones, and don't need to know about anything else that might have happened on Flickr in the mean time then I suspect caching your own list is definitely the way to go in this use case.


Apr 24, 2011 at 11:11 AM

Hi Sam,

Althought it makes sense when I think about it, I didn't realise you were caching the XML from Flickr... I assumed you'd be caching FlickrNet's own objects which would be easier to create and maintain.

I'll just implement my own caching in my own application.

Thanks for the responses.