Separating cache key and cache content concerns

[Simon Bulman]

Hi there,

I have been exploring RoboSpice for a little while now and like it. I am struggling however to design / implement the following use case using the retrofit extension:

1. Execute a GET request that gets a list of People => by default this is cached in a file that contains the JSON response (all people)
   
2. Execute a GET request that gets a single Person => by default this is cached in a file that contains the JSON response (single person)

So, we now have two cache files than contain data for the same Person (the assumption is that Person returned in (2) is also in the list (1)). This seems counter-intuitive to me. If the data of the Person had been changed (on the server) between (1) and (2) the representations are inconsistent and if views are binding to the different representations we have a usability problem.

My initial thinking was to implement a Persister that would decompose the contents of the list (1) and cache each Person individually. Then when (2) is executed the cache for the single person would be updated (rather than duplicated). To achieve this, there would need to be some notion of identity for the Person so the correct cache could be found.

This is where I am getting stuck, the cache key is 'kind of' getting in the way here. Grabbing stuff from the cache, working out if stuff is stale, updating the cache, etc. seems to be intrinsically tied to the request (e.g. the cache key) rather than based on the contents of / types in the cache. For example, I would like to be able to check the staleness of all People cached and if older than X re-execute (1) (or even better only fetch data from the server for the subset of People that are stale).

Am I missing something fundamental here? Am I trying to bend the system to far? Have others solved similar scenarios?

Thanks,

Simon    

[Nikola Keskinov]

Hi Simon,

I have experienced a similar scenario and still haven't found a generally acceptable solution for it. Currently, when I know a single item has been invalidated, I refresh the complete collection of items from server. This is far from ideal, but it fits the project I am working on and compensates for some other constraints it has (like having no push notifications).

But otherwise, I completely agree with your idea. About the challenges you have, I think the cache keys are still a good solution, as you can work with them both in the SpiceRequest and your custom ObjectPersister implementation.

Another point worth mentioning is the RoboSpice ORMLite extension which can potentially solve the problem with having hierarchical data, but I haven't examined that one enough to say more.

Regards,

Nikola