Problem/Motivation
VIewsData uses 'views.settings':skip_cache in order to skip its caching. This is an additional setting, without the actual need for it otherwise on runtime.
Proposed resolution
Get rid of the usage and let people just use a different cache backend for '@cache.discovery'. In case they really care they could also inject the null backend
by using a custom services.yml file.
Remaining tasks
User interface changes
API changes
Data model changes
| Comment | File | Size | Author |
|---|---|---|---|
| #47 | 2541074-47.patch | 988 bytes | lendude |
| #40 | 2541074-40.patch | 12.27 KB | lendude |
| #40 | interdiff-2541074-38-40.txt | 2.27 KB | lendude |
| #38 | 2541074-38.patch | 11.62 KB | lendude |
| #38 | interdiff-2541074-36-38.txt | 2.2 KB | lendude |
Comments
Comment #1
dawehner.
Comment #2
martin107 commentedI am working on this now.
Comment #3
dawehnerThis probably needs a short doc how to bypass caching for views
Comment #4
martin107 commentedI really like the idea behind this issue... I think it will, in the end look much simpler.
This is not ready for review.... the changes are spread across too many files, 9 , and I have little confidence that I will make all the changes in the first draft.
I am looking to testbot to point out anything I have missed.
What can I say
1) Site install works.
2) ViewDataTest passes.
3) Views UI settings forms test passes.
Comment #5
dawehnerReally like the idea!
No, this won't be NULL but rather the Null cache backend. its kinda a difference :)
Two whitespace before ModuleHandlerInterface :P
There you can cleanup the code also a bit more
Comment #6
damiankloip commentedHmm, I am not sure about this tbh. Instead of the config option, you need to:
- Override the service definition for views_data, and inject a Null/memory backend instead
- Use Null/memory backend for the cache_data bin
That's not quite as obvious for 99% of people? But on the other side, do we really need this setting to disable the cache? Can we live without it..
Comment #7
martin107 commented1) Oh Good Grief Charlie Brown -PEBKAC - Ok well on the bright side I learn something new every day!
2) Fixed.
3) Yes, same applies to cacheSet(). If you are supplying a null cache backend its behaviour is well defined ..
Its seems an over-complication to mention that corner case in the methods documentation anymore so I have dropped any mention of it.
Same tests pass locally.
PEBKAC - The Problem exists between keyboard and chair.
Comment #8
dawehnerWrite you need both the entry in the settings.php + services.yml file, but still this is quite an edge case, as you wrote.
Comment #9
damiankloip commentedComment #10
martin107 commentedComment #11
martin107 commentedCan I ask what aspect of the change should be documented in a change record.
That the configuration element views.settings':skip_cache is going away ?
Comment #12
dawehnerYeah document that the setting is removed and there these are the steps to opt out of that caching.
Comment #13
martin107 commentedThank you .. I am drafting the change record now.
Comment #14
martin107 commentedHere is the first draft of the cr.
Comment #15
dawehnerThis is not entirely obvious, to be honest. I would vote for listing all the needed steps.
Comment #16
martin107 commentedFair point.... I am out of time today .... tomorrow is another day
Comment #17
martin107 commented@dawehner - I have a quick question
Are developers commonly going to alter the existing service or provide a parallel service?
SO
A) Should I provide an altering service guide, something very similar to https://www.drupal.org/node/2026959
OR
B) Describe how to provide a new service.
My knowledge of the various use cases is not good enough so say definitively.
Comment #18
dawehnerIMHO we should at a cache.null cache bin in the development.services.yml and provide a commented out example in there which uses this new cache bin
Comment #19
dawehnerAnd the CR basically document that and point to development.services.yml
Comment #33
lendudeNot a bug I'd say, and not a useful setting, as described, there are other ways to temporarily disable this cache if you are working at ViewsData development, and there is really no other use for this that I see.
Reroll, let's see what I got wrong!
Comment #34
lendudeCS clean up
Comment #36
lendudeAdded update to clear the setting from config, not adding a test for it since the fails in #34 show we have coverage for this.
Comment #38
lendudeUpdate tests to match the new flow.
Comment #39
spokjeI think we need to do the deprecation-dance here (as specified in https://www.drupal.org/about/core/policies/core-change-policies/drupal-d...)?
Comment #40
lendudeToo right, thanks @Spokje
Something like this I guess.
Comment #41
spokjeWell, since I'm already being annoying, we kinda need a CR and the deprecation notice needs to link to that.
(Also CRs are being watched by people working on Rector/PHPStan Drupal-related magic)
Comment #42
lendudeIt has a CR and it is linking to that :)
The NIDs are just eerily similar https://www.drupal.org/node/2541974
Comment #43
spokjeMeh!
Yes, and also in the 2 million-range, so I never expected a CR so old...
I've looked at the code and all seems well enough for an RTBC.
Comment #45
catchCommitted/pushed to 11.x, thanks!
Comment #46
markdorisonThe associated change record notes this is being introduced in 10.2.0, but the metadata and commit here seem to indicate 11.x. Is the change record incorrect?
Comment #47
lendudeGood question, since it has an update and removed something, I'm gonna assume it will probably not be backported to 10.2, so quick follow up to adjust the deprecation message to mention the correct versions
Comment #48
catchJust to clarify, 10.2.x will be branched off 11.x around when we get to alpha. https://www.drupal.org/about/core/blog/new-drupal-core-branching-scheme-... has the details.