When results are being cached I'm hoping we can 1) count the results and save them and 2) later use those counts to show how many results adding a parameter from an exposed filter will result in. This is similar to how the Apache Solr module's facets display how many results will be presented if selected. I'm looking at the view_content_cache code for the first time right now looking for a way to accomplish these two things. Any tips?

Comments

R.J. Steinert’s picture

R.J. Steinert commented

In the cache_views_data table where the cid column looks like {view id}:{display id}:results:{hash}, the Data column contain a serialized array containing a property call total_rows. Win! That's my first requirement :)

Now it's time for part 2, use those counts to show how many results adding a parameter from an exposed filter will result in. I need to figure out how Views/Views Content Cache knows which row in the cache_views_data table to use. When I understand how that works, then I believe I'll be able to use that logic to determine what cached data to grab according to all of the user's next possible moves (a move being the act of selecting a parameter in an exposed filter).

Lastly, when I have all of the correct cached data sets, I'll figure out how to alter the exposed filter parameters to display these counts. I might have to do the applying of these counts using javascript on the client side given that I'm seeing the exposed filter forms in the cached output.

steven jones’s picture

steven jones commented
Project: Views content cache » Views (for Drupal 7)

This question is related to Views caching in general, and I don't think it is specific to Views Content Cache.

It's pretty much up to the cache plugin what the cache key is, so I don't think trying to work out the cache key is the way to go, you can just ask the plugin, but actually, you could probably just get the view to execute the query, and not render, and then grab the total rows. If the view was set up with a cache, then this would get returned from cache (hopefully) otherwise it just falls back to using the query backend.

R.J. Steinert’s picture

R.J. Steinert commented
Status: Active » Closed (works as designed)

@Steven I think you've made a great point. I was initially thinking going directly to the cache table but ideally calling view::execute() shouldn't really be all that heavier than whatever I write. Thank you so much for getting back to me.