View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0006894 | OXID eShop (all versions) | 4.08. Cache | public | 2018-08-29 10:27 | 2018-09-03 11:56 |
| Reporter | dx_bhesse | Assigned To | |||
| Priority | low | Severity | minor | Reproducibility | always |
| Status | acknowledged | Resolution | open | ||
| Summary | 0006894: Caching in CategoryList does not reflect filters applied in _getSelectString() | ||||
| Description | In 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 Reproduce | 1) 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 Information | Instead 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 | ||||
| Tags | No tags attached. | ||||
| Attached Files | |||||
| Theme | Not defined | ||||
| Browser | Not defined | ||||
| PHP Version | Not defined | ||||
| Database Version | Not defined | ||||
|
|
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] |
|
|
>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. |
|
|
Here the missing cc_run1_output.html |
|
|
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] |
|
|
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...) |
|
|
Since it's acknowledged, our product management will decide about the next steps. Thanks for the further information. [sp] |
