Context:
- I have a View based on a S.API. index of nodes of given type with an exposed filter (Search: Fulltext search) that acts as a search box
- Views is patched with https://drupal.org/node/1055616#comment-8610445 (to kill a remarkably similar bug to this reported here, seen with the default Drupal search system used previous to this context)
- Both exposed filter and search results displays are in panel regions on a panel page (panel caching DEACTIVATED)
- Views caching is activated "Search Specific" + "1hour/1hour" for the caching of query and rendered results respectively

A first search in the exposed filter returns results listing as expected.
A second search for totally different terms (with no chance of overlap mistake) return exactly the same results

>>> Deactivate "Rendered results" caching and the problem goes away...

So, the patch above to views fixed almost exactly this issue (as seen from the UI) ... so is it possible that code in S.API views interaction is causing this? Perhaps the patch is causing this...

Any one seen this?

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

aheimlich’s picture

I know that there were changes made to the way Views generates cache keys in 7.x-3.8 (see http://cgit.drupalcode.org/views/commit/?id=0cb96e5269a5479498b6ca9f5176...). Looking at Search API's Views cache plugin, it doesn't appear to take those changes into account. Specifically, $this->view->result is no longer used in generating the output cache key.

nicola85’s picture

FileSize
1.36 KB

The attached patch fix "Search-specific" caching system with Views 3.8

daveferrara1’s picture

Yep seeing it on our site. Cache set in views causing queries to fail. Trying the patch now.

mariacha1’s picture

Status: Active » Needs review
FileSize
1.88 KB

This was happening for us as well. The patch fixed it and looks sound.

The only issue is that if you haven't upgraded to views 3.8, the previous patch breaks caching in exactly the same way. So we'll need to make sure the site is running the latest version of views as well.

Adding that to the .info file with the enclosed patch, which is otherwise identical to the patch in comment #2.

drunken monkey’s picture

Status: Needs review » Needs work

Thanks for reporting this problem and thanks to nicola85 for already providing this patch!
However, I wouldn't want to add a versioned dependency to the module, and especially not to such a recent version (that might also break other contrib modules, I guess).
Can we not just also add a get_results_key() method that contains exactly the same as the parent in 3.8? Would that maybe work with both? I'd really like to be compatible with both, if possible.

drunken monkey’s picture

Title: Activating "Rendered output caching" breaks Search API based view » Adapt to latest changes in Views cache handlers
Category: Bug report » Task
dbassendine’s picture

+1 - we were seeing the same issue, and the patch resolved it.

Exploratus’s picture

I was having the same problem. Patch worked for me.

drunken monkey’s picture

As said, it would be great if someone could provide a patch that works with both Views versions.

areynolds’s picture

Status: Needs work » Needs review
FileSize
2.11 KB

Ok, re-rolled this based on @drunken monkey's suggestion, works based on my testing.

One (semi-related) question: why is the cache plugin .inc file called plugin_cache.inc in search_api_views? The handler name for the cache plugin is "SearchApiViewsCache", but the hook_views_plugin() documentation says that the "handler" attribute should be both the name of the file and the handler function. I'd expect the .inc file to be called "SearchApiViewsCache.inc" (or to rename everything to "search_api_views_cache", which would follow the Views naming convention better). I can't even get the search_api_views cache plugin to load in my debugging unless I do one of those two things...

Status: Needs review » Needs work

The last submitted patch, 10: search_api_views-patch_views_cache-2281535-10.patch, failed testing.

areynolds’s picture

Oops, that patch was based on 7.x-1.x, here's one for 7.x-1.12.

areynolds’s picture

Status: Needs work » Needs review
mariacha1’s picture

Status: Needs review » Reviewed & tested by the community

Patch #12 works with both views 3.7 and views 3.8, from my tests. Setting to RTBC.

drunken monkey’s picture

Status: Reviewed & tested by the community » Fixed

Great job, thanks a lot. Seems to work fine for me, too.
Committed.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.