Project

General

Profile

Actions

Bug #28589

closed

Autoloader Cache is not updated

Added by Oliver Hader over 12 years ago. Updated over 5 years ago.

Status:
Closed
Priority:
Should have
Assignee:
-
Category:
-
Target version:
-
Start date:
2011-07-30
Due date:
% Done:

100%

Estimated time:
TYPO3 Version:
4.6
PHP Version:
5.3
Tags:
Complexity:
Is Regression:
Sprint Focus:

Description

The autoload registry contents are stored in a separated PHP level caching in TYPO3 4.6.
There are already several mechanisms to flush the cache, e.g. on installing a new extension.

However, during development (and also maybe during TYPO3 Source Updates) new classes in the registry files are not considered.

Now, there are several ways to solve that:
  • if we rely on the extension manager to flush the cache on updates, we just would need the cacheIdentifier contain e.g. the TYPO3 version number
  • if that does not help, we need a way to find out whether a registry file was modified (e.g. MD5 hash of that file)
  • if that all does not help or is too expensive, we could use a lifetime for those caches (of course does not help during development and patch reviewing)

Related issues 2 (0 open2 closed)

Related to TYPO3 Core - Bug #28598: [Cache] Let NullBackend implement PhpCapableBackendClosed2011-07-30

Actions
Related to TYPO3 Core - Bug #28266: When an extension is installed or removed, the autoloader cache must be flushedClosed2011-07-17

Actions
Actions #1

Updated by Mr. Hudson over 12 years ago

Patch set 1 of change I4fa47178016925f39ff2168f65afb1ae357be556 has been pushed to the review server.
It is available at http://review.typo3.org/3903

Actions #2

Updated by Christian Kuhn over 12 years ago

@Oliver: I'd strongly recommend to abandon this change set.

I've instead now pushed https://review.typo3.org/#change,3911 The patch enables usage of the NullBackend for the phpcode cache to easy development on a dev system. This is also very useful for the new language cache ...

I've also documented this switch in the caching framework documentation at http://wiki.typo3.org/Caching_framework

Actions #3

Updated by Oliver Hader over 12 years ago

Hey Christian,

I know that each check (and file system operation) on each request slows down the scenario. So, see it as a draft...

We should however still consider these stories:

1) "As developer I want to test the feature at https://review.typo3.org/#change,3359 which add a new class file to TYPO3"
-> seems to be okay, since most developers should be able to handle that
  • either set the NullBackend
  • delete files in typo3temp/cache/
    Suggestion: Since we already have the hardcoded context "production" we could move that to config_default as all - and hard "development"

2) "As TYPO3 integrator and editor I want to check out the most recent version of TYPO3 and upgraded locally from TYPO3 4.6.0 to 4.7.0alpha2"
-> probably the system is running in production mode and new classes in the next TYPO3 version will stop the system from working
Suggestion: Add TYPO3 version number to cache identifier

Summary:
  • drop my MD5_file() stuff in the recent patch
  • introduce context mode to TYPO3 - production/development
  • add TYPO3 version number to identifiers of system wide caches
Actions #4

Updated by Björn Pedersen over 12 years ago

Hi,

Story 2) could be taken care of by the upgrade wizard in the install tool, as this wizard is needed on major version upgrades anyway ( DB schema changes...).
so: add a clear all (low-level) caches to the install tool ( should also clear e.g. the RTE cache and the temp_cached_ files).
This way, we don't need a version number anymore.

Actions #5

Updated by Mr. Hudson over 12 years ago

Patch set 2 of change I4fa47178016925f39ff2168f65afb1ae357be556 has been pushed to the review server.
It is available at http://review.typo3.org/3903

Actions #6

Updated by Christian Kuhn over 12 years ago

@Oliver:

Your suggestions are great! Actually, I introduced the TYPO3_version addition to the identifier before I read you post of this issue again (see latest patch version in gerrit).

And yes, we are on the same track with the production / development context thing, but I think we need a broader implementation and interface for this (I'd love to have it!). We are currently beyond 4.6 feature freeze, so a solid implementation will not make it for 4.6 anymore. For 4.7 we have plans for a better bootstrap, and this one could possibly consider a context as well. So, I'd like to shift the context thing a bit and maybe work on it for a later version, the caching framework even has methods for it.

Imho the current patch set should do for 4.6, we can ease the development issues with a later version.

Actions #7

Updated by Mr. Hudson over 12 years ago

Patch set 3 of change I4fa47178016925f39ff2168f65afb1ae357be556 has been pushed to the review server.
It is available at http://review.typo3.org/3903

Actions #8

Updated by Oliver Hader over 12 years ago

  • Status changed from New to Resolved
  • % Done changed from 0 to 100
Actions #9

Updated by Benni Mack over 5 years ago

  • Status changed from Resolved to Closed
Actions

Also available in: Atom PDF