Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
#81461: Clean up the cache API (stop overloading function arguments, remove procedural wrappers) changed the cache API, but left a backwards compatibility layer in.
#1272686: convert existing cache_* calls to the new cache()-> API is for converting all of core to use the new API.
This issue is for removing the backwards compatibility layer when that's done. I am going to try to get a patch done for that early, so it's ready when all the other patches are committed. This might need a bit of review since it is likely to involve at least some documentation changes.
Comment | File | Size | Author |
---|---|---|---|
#52 | cache_bc_removal_1272706-52.patch | 18.57 KB | msonnabaum |
#50 | cache_bc_removal.patch | 18.57 KB | catch |
#46 | cache_bc_removal.patch | 25.96 KB | catch |
#43 | cache_0.patch | 25.42 KB | catch |
#38 | cache.patch | 25.24 KB | catch |
Comments
Comment #1
catchAlright, this is going to fail hard, however it should hopefully pass once #1272686: convert existing cache_* calls to the new cache()-> API is complete.
There are a few docs changes here - i.e. I've removed a listing of specific cache bins since those are provided by system and other core modules, not the API itself, and should be documented elsewhere already.
Marking needs review to see how bad it is.
Comment #3
pounardSub, will help when I'll have some spare time.
Comment #4
catchIronically we can't actually remove cache_clear_all() yet since that function is hard wired to the block and page caches.
That's the job of #636454: Cache tag support to kill. So adding it back for now :(
Comment #5
pillarsdotnet CreditAttribution: pillarsdotnet commentedWhy is this critical?
Comment #6
catch@pillarsdotnet. Just so that we don't end up shipping Drupal 8 with two cache APIs. Typing from phone so can't find link but there's an issue 'strategies for far reaching core patches' where this is being discussed.
Comment #7
pillarsdotnet CreditAttribution: pillarsdotnet commentedOkay; wasn't trying to be argumentative; just wanted to hear the rationale. Thanks.
Comment #8
catch#1272686: convert existing cache_* calls to the new cache()-> API was committed.
Comment #9
catch@pillarsdotnet, that issue is #1272266: Strategies for far-reaching core patches fwiw.
Comment #11
BerdirI was able to get the installer working together with #1275808: Use new cache bin naming in hook_flush_cache and porting a last remaining cache_get_multiple() call (which is I think the only one in core and was probably forgotten because of that).
I also updated a few remaining mentions of cache_get(), cache_set(), cache_get_multiple() with something I found appropriate, please review. The interdiff shows them.
Leaving at needs work, change to needs review once the linked issue is commited.
Comment #12
BerdirFixed the trailing whitespace :)
Comment #13
yched CreditAttribution: yched commentedIf I read the patch correctly, this should now be cache('field') ?
Powered by Dreditor.
Comment #14
BerdirAbsolutely.
Comment #15
bfroehle CreditAttribution: bfroehle commentedMarking to needs review now that #1272686: convert existing cache_* calls to the new cache()-> API and #1275808: Use new cache bin naming in hook_flush_cache are in.
Comment #16
bfroehle CreditAttribution: bfroehle commentedWe're still not quite there yet:
Two issues:
Comment #17
Anonymous (not verified) CreditAttribution: Anonymous commentedsubscribe.
Comment #18
Paul Simard CreditAttribution: Paul Simard commentedWould a possible solution for the cache_clear_all() problem be changing
to something on the order of (please ignore likely syntax errors)
It would permit all ooccurrences of cache_clear_all();
to be replaced by cache('all')->flush();
Just a quick thought off the top of my head. No idea how it would impact the code otherwise. If this isn't the solution, well, sorry I spoke up. :)
Comment #19
Paul Simard CreditAttribution: Paul Simard commentedComment #20
catchI'm hoping to remove cache_clear_all() (finally) with #636454: Cache tag support although there's a long way to go there before we can do it.
We might want to rename it to something like 'cache_clear_content()' temporarily though so it fatals for people using the old API.
Left it as is for now though.
For menu_cache_clear(), I discussed this in irc with beejeebus and chx, as well as looking at the original issue where it was introduced. #1010480: Optimize _menu_navigation_links_rebuild() massively cut down the number of times this can be called in the first place, so this patch just does a normal cache()->deletePrefix() rather than trying to port that pattern. Also fixed the 'cache_page' reference in the cache test.
Comment #21
klausidouble quotation mark here instead of white space
line breaks too early here
Comment #22
pillarsdotnet CreditAttribution: pillarsdotnet commentedRe-rolled #20, reformatting comments in includes/cache.inc in response to #21 and similar concerns. No code changes.
Comment #23
Lars Toomre CreditAttribution: Lars Toomre commentedWhy is patch in #22 so much larger than #20? I suspect that some extra stuff was included rather than are-roll with small text changes.
Comment #24
pillarsdotnet CreditAttribution: pillarsdotnet commentedPatch #22 is larger because it corrects errors in the comments that were not corrected by patch #20, in order to make the documentation meet current coding standards.
Here's the interdiff, with annotations:
Correct run-on sentence error.
Expand "e.g." to "For example".
Add a blank line before the code example.
Wrap at 80 characters.
I figured that if people were going to mark this patch as "needs work" because of pedantic comment formatting errors, we might as well proactively fix all of them at once.
Comment #25
Lars Toomre CreditAttribution: Lars Toomre commentedThanks. All of those text and documentation changes look good!
Comment #26
catch#22: cache_remove_bx-1272706-22.patch queued for re-testing.
Comment #28
pillarsdotnet CreditAttribution: pillarsdotnet commentedRe-rolled #22 to correct fuzz.
Comment #29
Lars Toomre CreditAttribution: Lars Toomre commentedSorry but zero byte patch attached in #28.
Comment #30
pillarsdotnet CreditAttribution: pillarsdotnet commentedThanks, Lars. Trying again...
Comment #32
pillarsdotnet CreditAttribution: pillarsdotnet commentedTrying again...
Comment #34
pillarsdotnet CreditAttribution: pillarsdotnet commentedWell, it installs locally now...
Did a grep for cache_set and cache_get -- think I caught 'em all.
Comment #35
catchThis looks good to me. One thing I'd like to discuss. I'm hoping that if we can get #636454: Cache tag support in, we can eventually remove cache_clear_all() altogether.
As it is, we've left cache_clear_all() in, existing code calling that function is going to get silent failure (it won't clear their caches properly but nothing will complain either). Is it worth throwing an exception if (func_get_args()) or similar? If people don't fancy doing that, then otherwise I think this is RTBC.
Comment #36
catchHere it is with the exception. If we're successful removing cache_clear_all() during the D8 cycle via #730060: Replace CACHE_TEMPORARY, cache_clear_all() and minimum cache lifetime with cache tags support then the exception will be removed at the same time. While it's there it's a hard fail for people chasing HEAD instead of failing silently though.
If people don't like this version, then #34 would be RTBC for me anyway.
Comment #38
catchI think I uploaded the same patch again :(
Comment #39
tstoecklerI think such an Exception makes sense. I'm setting to 'needs work' because of the "0 passes" wich are deceivingly green.
Comment #40
yched CreditAttribution: yched commented"needs work" as per #39
Comment #41
Berdir#38: cache.patch queued for re-testing.
Comment #43
catchRe-rolled for /core. Didn't look into 0 passes at all yet.
Comment #44
BerdirStill 0 passes, looking at the review log you can see that the tests *are* run but there are a number of exceptions like this one:
Actually, there are *hundreds* of those. And finally, MySQL is giving up and dies:
Conclusion: This patch kills the test bot :)
Comment #45
BerdirFound a remaining cache clear all call in menu.inc:
And one in locale.inc:
That last one was probably added by one of the recent i18n patches, not sure about the first.
Comment #46
catchThis fixes the locale clear (I changed that to cache_clear_all() - since if it's supposed to update the interface it should update cached blocks too, we could change it to cache('page')-flush() though if people think that's overstepping the bc removal).
The patch already removes the call in menu.inc.
Let's try again, proves the exception makes things blow up hard I guess.
Comment #47
catch#46: cache_bc_removal.patch queued for re-testing.
Comment #48
catch#46: cache_bc_removal.patch queued for re-testing.
Comment #50
catchRe-rolled, this might not catch any new uses of the old API that crept in. Patch is a bit smaller than the previous one but that may be other patches slowly using the new API, also there were some docs fixes snuck in here which have since been committed in docs cleanup patches I think.
Comment #51
pounardI followed the cache evolution various threads since a long time ago, and read the patch once again: it's definitely RTBC now that it passes tests. If it's not included now some people may end up by commiting code based on removed functions here and it will continue to delay it indefinitely.
Comment #52
msonnabaum CreditAttribution: msonnabaum commentedThis patch fixes a small indentation mistake. Leaving as RTBC as it makes no other functional change.
Comment #53
catchAlright, committed/pushed this to 8.x.
I'll ping pounard about possibly opening a 7.x-1.x branch of http://drupal.org/project/cache_backport (which would 7.x sites could have a cache API that looks the same as 8.x did with the bc layer still in).
I've updated http://drupal.org/node/1272696 for the change notices.
Comment #54
pounardPong. Good idea indeed.
Comment #55
David_Rothstein CreditAttribution: David_Rothstein commentedFollowup: #1394648: The installer's cache backend no longer overrides all cache-clearing methods, which can lead to fatal errors
Comment #56
pounardSorry for changing the state, this patch is OK definitely but we have to put a priority between this patch and #1323120: Convert cache system to PSR-0, which one are we going to commit first?
Thanks a lot to David_Rothstein for raising this point.
Comment #57
catchWe already committed this one, did you mean a different issue?
Comment #58
pounardPlus this patch does not fix the install backend, it makes its clear() method silent and risk to awake the ugly side effects we had before it has been created.
Comment #59
pounardWhen has it been commited? Didn't see conflicts applying my patch yesterday?Ok understood, the namespacing patch retintroduce the clear() method because it was started before, and now it doesn't create any conflicts because it creates fully new files.