Open chrissearle opened 10 years ago
This is the cache on the NSFetchedResultsController on the Settings view.
Right now I'm going to set cacheName nil but as a workaround - not necessarily a fix. Running out of time here.
I'm not sure that this screen needs a cache - it's not often used.
Going to remove from milestone for now - this is low pri since it runs fine without the cache and is low usage.
I´m not sure if this is related, but found this:
Important: If you are using a cache, you must call deleteCacheWithName: before changing any of the fetch request, its predicate, or its sort descriptors. You must not reuse the same fetched results controller for multiple queries unless you set the cacheName to nil.
Yes - that makes sense in fact.
We can either reinstate the cache and add that call - or just not have a cache (the main view doesn't have a cache because user interaction changes the predicate fairly often).
I'm not sure that this view is used enough that it's worth adding the cache back with the extra complexity of handling cache deletion under all correct circumstances. Nor is the list that long.
If you head to the settings / conference list - then choose the active conference then the delete all button (this was added mostly for me but also to give me something to ask users to click if data got corrupt) then when you return to the conference list it has correctly cleared the data - but when you then OK back to the session list - it throws an internal consistency error on the fetched results list.