Project

General

Profile

Actions
Copy link

Bug #64272

closed

extbase query cache does not factor in start/stop times for pages

Added by Nils Blattner almost 10 years ago. Updated about 7 years ago.

Status:
Closed
Priority:
Should have
Assignee:
-
Category:
Extbase
Target version:
-
Start date:
2015-01-14
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
6.2
PHP Version:
5.4
Tags:
Complexity:
hard
Is Regression:
No
Sprint Focus:

Description

Hi there

When extbase caches queries, it does not factor in start/stop times of pages that should be searched.

=> tx_myext_domain_model_something.pid IN (1285,1284,1283,1282,1281,1280)

If now page 1285 has a stop time in the future, it will not be removed and if there is a page 1289 with a start time in the future, it will not be added.
This can of course be mitigated with a lower time to live, however a different solution is desiarable. (Btw. the default lifetime is way too high)

=> How about the query cache collects start/stop times of the underlying pages (and possible pages) and factors them into the lifetime of the query cache entry
=> Additionally tags, that get deleted upon changes in the backend for these pages, is desirable

What do you guys think?

Can be reproduced:
=> Extbase Plugin with a page in the plugin options as data storage + recursive set
=> Subpage of the data storage which has a "start time" in the future and some entries inside
=> Call to the frontend => entries from said page are not shown (query cache entry is created now)
=> Wait until start time elapses
=> Clear frontend cache
=> Call to the frontend => entries are still not shown, even tough they should be

Cheers
Nils

Actions
Copy link

Also available in: Atom PDF