View Issue Details

IDProjectCategoryView StatusLast Update
0006894OXID eShop (all versions)4.08. Cachepublic2018-09-03 11:56
Reporterdx_bhesse 
PrioritylowSeverityminorReproducibilityalways
Status acknowledgedResolutionopen 
Product Version 
Target VersionFixed in Version 
Summary0006894: Caching in CategoryList does not reflect filters applied in _getSelectString()
DescriptionIn an Oxid EE (current git-version - as of writing commit-id: 7a024c192f91c31136be0b341d7d06a189a378da):
getCacheKey() includes the shop-id and the language, but does not include any filters applied in _getSelectString() like the "current category" in _getDepthSqlUnion() or the load-level in _getDepthSqlSnippet()

getCacheKey(): https://github.com/OXID-eSales/oxideshop_ee/blob/master/Application/Model/CategoryList.php#L130
_getSelectString(): https://github.com/OXID-eSales/oxideshop_ce/blob/master/source/Application/Model/CategoryList.php#L179

Depended on the order the "oxcategorytree_X_Y.cache"-file is generated, it contains incomplete/wrong data for another CategoryList-instance with other filters applied
Steps To Reproduce1) Clear cache
2) Init CategoryList with setLoadFull(false), and buildTree() with any category
3) Cache file will be generated by load() called in buildTree()
4) Init CategoryList with setLoadFull(true) and buildTree() with another category as argument
5) Cached data will be reused by load(), but the cached data from previous load from step 1 might not contain all wanted data for step 4 (depending on the categories used as arguments for buildTree())
Additional InformationInstead of completely disabling the cache, a quick workaround might be to include a hash of _getSelectString() in getCacheKey()

Probably related: https://bugs.oxid-esales.com/view.php?id=6410
TagsNo tags attached.
ThemeNot defined
BrowserNot defined
PHP VersionNot defined
MySQL VersionNot defined

Activities

QA

2018-08-30 09:12

administrator   ~0012594

Last edited: 2018-09-03 11:55

View 2 revisions

It's correct, that the filters don't get stored in the cache files. Though this isn't a bug, because it is not supposed to be like you requested. So this part is actually a feature request.

Nevertheless it looks like you also want to describe another behavior resulting from the issue mentioned right before. Unfortunately I can not get the point of your description. The cache file stores the category independently from the filters. You can create the cache file with and without filters and diff the files - they are the same.

In summary, what I currently get from your issue description is a feature request for adding the filters to the category caching system. If that is not what you wanted to tell, please provide some more (detailed) information about your concern.

[sp]

dx_bhesse

2018-08-30 13:37

reporter  

cc_run1.php (3,400 bytes)

dx_bhesse

2018-08-30 13:37

reporter   ~0012596

>It's correct, that the filters don't get stored in the cache files.
The filtered data gets stored - Thats the issue.
>You can create the cache file with and without filters and diff the files - they are the same
Only if the cache was not cleared between two different calls - and the data stored in the cache is then wrong for the second call.

cc_run1.php is a sample script:
1) From line 11: Cache is cleared and CategoryList->buildTree() for category-id '0f4fb00809cec9aa0910aa9c8fe36751' (Kites) is called with setLoadFull(true) and setLoadLevel(1) before calling buildTree
2) From line 27: Cache is cleared and CategoryList->buildTree() for category-id 'fad569d6659caca39bc93e98d13dd58b' (Sportswear) is called with setLoadFull(false) before calling buildTree
3) From line 45: step 1 is repeated without clearing the cache first - now the output differs from the output of step 1

cc_run1_out.html is the output of the script.
The output of step 1 + 3 should be the same, with and without having the cache enabled.

dx_bhesse

2018-08-30 13:39

reporter   ~0012598

Here the missing cc_run1_output.html

cc_run1_output.zip (752 bytes)

QA

2018-08-30 15:18

administrator   ~0012599

Last edited: 2018-09-03 11:56

View 2 revisions

Thank you for your script and the further explanation. While you were working with a script, I have tested the issue only with the shop itself. In this case, the _blForceFull parameter is always set to true, so filtering isn't important for the caching mechanism. Like I mentioned before, cache file is generated without including the filters. Anyway, now I understand your concern and will acknowledge the issue as a bug. Since the option _blForceFull is always set to true and there isn't any execution of CategoryList::setLoadFull(false) in the shop itself (except one old test), priority is lowered.

[sp]

dx_bhesse

2018-08-30 15:36

reporter   ~0012600

As a small added note:
We actually noticed the problem in a shop where the "digidesk evomenu"-module is used.
When the Oxid-EE Cache was enabled, the menu had missing subcategories and we tracked down the problem to the CategoryList class.
Probably the evomenu calls buildTree() without setLoadFull(true) before any oxid-code does.
The currently used workaround is to extend getCacheKey() and force a setLoadFull(true) there

(low priority is ok - we just wanted the problem to be known...)

QA

2018-08-30 15:46

administrator   ~0012601

Last edited: 2018-09-03 11:56

View 2 revisions

Since it's acknowledged, our product management will decide about the next steps. Thanks for the further information.

[sp]