Closed (fixed)
Project:
Drupal core
Version:
8.0.x-dev
Component:
cache system
Priority:
Major
Category:
Task
Assigned:
Unassigned
Issue tags:
Reporter:
Created:
5 Jul 2015 at 11:24 UTC
Updated:
29 Aug 2015 at 20:24 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
pfrenssenAn implementation of this was already made for
AccessResultin patches #83-#87 of #2524082: Config overrides should provide cacheability metadata. That is going to be removed again from that critical issue so it can move forwards, we can then do the implementation here.The approach in that issue should be changed though so it is in line with what is done in #2525910: Ensure token replacements have cacheability + attachments metadata and that it is bubbled in any case. See comment #89 of #2524082-89: Config overrides should provide cacheability metadata.
Comment #2
jibran#2512718: EntityManager::getTranslationFromContext() should add the content language cache context to the entity is fixed.
Comment #3
berdirUse the trait, luke!
I was also waiting for #2525910: Ensure token replacements have cacheability + attachments metadata and that it is bubbled in any case to land, since that adds the addCacheableDependency() method to CacheablityMetadata that we also want on this interface.
This will conflict/overlap with #2524082: Config overrides should provide cacheability metadata which adds similar things as commented above and I think it's actually doing quite a bit that overlaps with this I think.
Noticed a few funky things in AccessResult:
* It doesn't initialize the properties but explicitly and manually resets them in the constructor. That seems like a weird pattern that we don't use elsewhere, so removed
* Those reset methods are actually public, they're not used anywhere except in unit tests and I really don't see the point of them. AccessResult seems like the perfect example of a refinable cacheable dependency, why would you even allow to reset those things? The interface was specifically designed to now allow that.
* It has a inheritCacheability() method that *almost* behaves like addCacheableDependency(), but something about the cache max age is different, if you try to just call the new method then some unit tests fail.
AccessResult currently also doesn't validate the cache contexts, so adding them kills tons of unit tests which now need a global container. Some even need that in the data provider, which seems to be called *before* setUp, so we might actually need to initialize that in there. That's just sad. Maybe we can get of those again with some optimizations on empty cache contexts/tags. I'll work on that next and then try to remove those changes again. The thing is that right now, we end up adding almost as much code as we can remove "thanks" to those test changes.
Tests don't fully pass yet but I think the above issue needs to solve the same unit test fail, so not bothering to to that work again here.
Comment #4
berdirAnd now with the patch.
Comment #5
berdirDoing a bit of optimization but it doesn't seem to help much with the test fails, since for example a cachePerUser()/Permission() adds a cache context and then it's calls it anyway.
Comment #8
wim leersRE: general
AccessResultweirdness: it predatesCacheableMetadataby many months.RE:
AccessResult::inheritCacheability(): that's because it really is designed fororIf()andandIf(). I wish we hadn't made it public. It first wasn't public.+1 to leaving it unchanged, but please know that this predates the existence of
Cache::mergeContexts()(which is what does the sorting for all other places in core).So, we should actually be able to remove this
sort().YAY!
If you want, I can take a look at the remaining test failures?
Comment #9
dawehnerThis test is problematic, because we access the container in the data provider which is wrong, as it doesn't work when you run it only via phpunit. We need to move the AccessResult object creation into the actual test method.
Comment #10
xanoI'm fixing the tests.
Comment #11
xanoApart from the obvious test failures, it's good practice to keep the data providers simple, e.g. provide a matrix of plain test data and keep the logic in the testing method. I fixed the methods where this went wrong, and had to mock
::getCacheContexts()and::getCacheMaxAge()in a few places. I hope those mocks behave correctly, and would appreciate feedback if what I did is wrong.Comment #12
dawehnerI could not resist earlier: http://privatepaste.com/ae8285ce8d
Comment #13
wim leersThe clean-up you did here to address #9 is beautiful! Thank you!
s/$field_storage_access/$field_storage_is_accessible/
This seems like an unnecessary bit of clean-up, and I'm not sure if it makes things actually cleaner/clearer?
Can you explain why you made this change?
Comment #14
berdirSee #9. It's not allowed to call out to the container in a data provider method, or at least a very bad idea.
Comment #15
berdirReroll, this is why I was waiting for that other issue to continue with this :)
Found one small bug there with the AccessResult unit tests ($this->maxAge = 0 when it should be $this->cacheMaxAge), but could remove a lot of code because that issue added it already and also fixed quite a few tests.
Converted one more provider. Still have an error on FormBuilderTest::testChildAccessInheritance. But I only get those errors if I run all the tests in tests/, not if I filter on running just that test.
Comment #16
berdirIgnore the first patch, start uploading and then fixed some unit tests...
Comment #19
berdirComment #20
wim leers#14: Oh, right, that results in indirect container calls. Thanks!
#15:
:)
Here's a full review.
If we're touching these lines anyway, let's also use
[].Yay!
Yay!
Sensible optimizations.
<3
Nit: inconsistent quotes. Fixed. Also reworded to fit on one line.
Nit: needless blank line. Fixed.
Same nit. Fixed.
RE: the
inheritCacheability()confusingness — I propose we deprecate that method in a follow-up (it's clearly out of scope). But what is in scope, is making it not duplicate that much anymore. So, I did that, and added docs explaining the difference. Nevertheless it is still quite confusing, which is why I think we should deprecate it in a follow-up, and remove at least the callers in core.Comment #21
wim leersThe patch in #19 is RTBC IMO. In #20, I only simplified and documented
inheritCacheability()to the extent that that is reasonably in scope for this issue.Therefore, if Berdir agrees with the changes I made in #20, I think this is RTBC.
Comment #22
jibranComment #23
borisson_I added a patch to use short-array syntax over the old array syntax in
resetCacheContextsandresetCacheTags. This was the only thing I noticed when reviewing the patch.Comment #24
wim leersOMG we totally lost track of this!
Comment #25
alexpott@borisson_ short array syntax is preferred not required, just recommended.
Lucky I run phpunit on commit :)
Unused use statements.
Comment #27
borisson_The failures seem to originate from this line:
\Drupal::service('cache_contexts_manager')->validateTokens($cache_contexts);in\Drupal\Core\Cache\Cache::mergeContextsThis piece of code was already added in a bunch of tests (RoleAccessCheckTest, DefaultMenuLinkTreeManipulatorsTest, EntityCreateAccessCheckTest, EntityAccessCheckTest, AccessManagerTest, UserAccessControlHandlerTest, EditEntityFieldAccessCheckTest), so I added that in PermissionAccessCheckTest and FormBuilderTest. MenuLinkTreeTest already had similar code (but it doesn't use prophecy yet, I can change that but that might be out of scope for this patch),
Attached patch also fixes the unused uses.
Comment #28
wim leersComment #29
borisson_Test still fail when running
phpunit -c core, so shouldn't be RTBC yet.Comment #30
wim leersOh. I misread.
Comment #31
borisson_So the reason those tests fail is because the
*providermethods call out to the service container. Making sure that the calls to the container (that happen in->addCacheContexts($contexts).Attached patch fixes
PermissionAccessCheckTest.FormBuilderTestandMenuLinkTreeTeststill fail, but those *providers are not as straightforward as the one in PermissionAccessCheckTest.Comment #32
wim leersComment #33
borisson_This should fix all the tests.
Comment #34
borisson_I'm not really happy with how "easy" it was to fix
FormBuilderTest, filed a followup to look at that in more detail: #2550933: Refactor FormBuilderTest::testChildAccessInheritanceComment #35
wim leersChanges here look great.
Like you indicated on IRC, the changes here look spotty.
However, these changes are merely changing both the input and the expected output to not have cache contexts. That's it.
Since this test is really only about testing the behavior of
#accessset to a forbidden access result at the root of a render tree, that is totally fine. The cacheability metadata is not essential for testing here. It's#access's support forAccessResultInterfaceobjects that we're testing.However, we can even continue to test cacheability here. Just don't test with cache contexts, which use an external service. Use
max-ageinstead :)NW for changing these from using the
usercache context tomax-age(pick any value you like, I'd say pick a fun number :)).Then, we should be able to finally get this in :)
Comment #36
borisson_Changed to use
max-age, also testing ifmax-ageis set.Comment #37
wim leersThese changes can now be reverted.
This is again specifically testing cacheability. We don't want to do that here, that's not what the test is about. So, then, let's remove the max-age stuff altogether, just like you had in the previous patch.
Comment #38
borisson_I discussed this in IRC with @Wim Leers, the patch in #36 is testing side effects and that shouldn't be needed. Reverted back to #33 and reuploading patch.
Comment #40
wim leersCame back green on DrupalCI, let's get this in finally :)
Hurray for more consistency in dealing with cacheability metadata!
Thanks for your patience, @borisson_!
Comment #42
wim leersCrazy errors like
Looks like testbot was temporarily broken. Re-testing.
Comment #44
alexpottCommitted 9435942 and pushed to 8.0.x. Thanks!
Thanks for adding the beta evaluation to the issue summary.
Comment #46
wim leersYAY! :)
Comment #47
wim leersUpdated https://www.drupal.org/developing/api/8/cache/cacheable-dependency-inter... to mention this: https://www.drupal.org/node/2541914/revisions/view/8784837/8784851