Make the cache respect db_rewrite_sql() and substitutions

One problem with this is that cache is not theo nly thing that uses build_info['query']. For example, the data there is displayed during preview, and I consciously do *not* want to display the rewritten version, because rewrites are subject to change and would add significant confusion.

I think we would have to provide a different version query to use as the key without changing the build_info['query'] one. But that also leads to problems with people trying to change this query.

Maybe we just need to run it through db_rewrite_sql prior to caching and live with running this twice. It's not a big deal there...we're caching.

One other possibility is that we could acquire the data from hook_node_grants() but that only works for node queries. Other things could be rewritten other ways. :/

I'm struggling with this on an open atrium site, that has ***CURRENT_GID*** in pretty much every view, which means I can't cache anything!

What work is outstanding to get this into the 2.x branch of views? or are we working on a solution in 3.x too?

I've added the meat of #2 to my caching plugin over here: #874506: Views caching flawed and it works just fine. So this fix for 2.x is working nicely.

We are waiting for a patch for 3.x

So what's the problem with the 3.x version of the patch

First http://drupal.org/node/835968

The db_rewrite_sql calls doesn't make sense here but they have to be runned before the checking of the cache plugin so they cannot be in query::execute.

So voxpelli and me discussed and decided to introduce a pre_execute function for query backends which is runned before checking the cache.

Okay here is a patch. This needs intensive review

I'm struggling with it too, in an OG-based Intranet project. (Views 2)

*hopes for a fix, willing to test*

@itsnotme Patch from #2 works fine with views 2.

Here is a small rerole because query settings went it.

I also tested the patch a bit, played around so i think earl could have a look at it

#2? (There is no patch.)

I tried #1 but it doesn't seem to have an effect...?

Sure #2 is #1

If you use the patch you have to clear every cache which views had stored.

I emptied all and any caches now, afais.

My expected result would be that I see a "Used cached results" line for certain time-cached views.

I get this for content-based views after applying the fix Stephen posted in#7.

The time-cached views are delivered in blocks. The output is handled correctly, aka shows "Used cached output". I have Views 2.8.

Patch in #13 does not apply.

I know this can't apply to 7.x

This one is kind of fun.

db_rewrite_sql does not exist so it might be impossible to get the query with/without the node access.

Unassign myself.

Personally i think this is impossible because the node access is runned during execute, but who knows.

At least the caching does currently uses preExecute to get a well query.

As preExecute is executed in the query you could argue that the rewritten sql is already part of the cache, so let's mark this as fixed.

So, is the caching in Views 6.x-2.x broken ?