This is a follow-up from #1055616: Query arguments should be replaced before generating cache ID

Display caches are missed unnecessarily.

Here is my analysis:
- After executing a cached display/view twiced, I find 1 results-record (which is OK), and 1 or 2 output-records (which is wrong) in table cache_views_data.

- after inserting a dpm() in function get_cache_key in, or enabling the Devel Query log,
I find that the ['build_info']['...query']['arguments'] names are not consistent (but only for the results-cache). Mostly they are ':db_condition_placeholder_8 ' to ':db_condition_placeholder_11', but sometimes from 12-15 .


dawehner’s picture

Status:Active» Postponed

So this issue should be postponed for now.

johnv’s picture

Status:Postponed» Active

Not really, since it is discovered in that issue (which deals with caching and exposed filters), but it can happen with every cached view, so it is an independent issue.

johnv’s picture

If anyone could point me to the location where the ':db_condition_placeholder_' is generated, I am happy to test and create patch

Arnaud Meunier’s picture

johnv’s picture

Yes, your change in #1430650-39: Taxonomy filter with depth, Drupal 7.12, and views query caching failure resolves the issue.
I reported back in #1055616-84: Query arguments should be replaced before generating cache ID.
I saw you issue before, but never had the time to test that use case. Perhaps you can confirm if it is the case?

johnv’s picture

Status:Active» Closed (duplicate)