Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Make collectstatic for cached static files more "atomic". #31

Closed
wants to merge 1 commit into
from

Conversation

Projects
None yet
2 participants
Contributor

mpessas commented May 5, 2012

The commit moves all cache set to the end of the post-processing phase
of the CachedStaticFilesStorage class. We do that by keeping a
dictionary of what needs to be stored to the cache and store that after
all static files have been post-processed. Additionally, existing cache
keys are never deleted; instead, we rely on the cache expiration to
remove not-recently-used keys.

This is convenient for deployments. Ususally, one first does a
collectstatic and then restarts his application servers. But since the
cache is (normally) shared with the currently running application
processes, any change to the static files will be immediately used for
existing requests. This results in having a previous codebase serving
newer static files, which might lead to issues.

The commit moves all cache handling to the end, so that the above window
of serving wrong versions of the static files is minimized. This has the
added benefit, that one can safely stop the collectstatic command in the
middle of the execution, without any impact on the existing application
processes (the old files are always there, anyway).

Make collectstatic for cached static files more "atomic".
The commit moves all cache set to the end of the post-processing phase
of the CachedStaticFilesStorage class. We do that by keeping a
dictionary of what needs to be stored to the cache and store that after
all static files have been post-processed. Additionally, existing cache
keys are never deleted; instead, we rely on the cache expiration to
remove not-recently-used keys.

This is convenient for deployments. Ususally, one first does a
collectstatic and then restarts his application servers. But since the
cache is (normally) shared with the currently running application
processes, any change to the static files will be immediately used for
existing requests. This results in having a previous codebase serving
newer static files, which might lead to issues.

The commit moves all cache handling to the end, so that the above window
of serving wrong versions of the static files is minimized. This has the
added benefit, that one can safely stop the collectstatic command in the
middle of the execution, without any impact on the existing application
processes (the old files are always there, anyway).

@jezdez jezdez closed this May 10, 2012

Contributor

jezdez commented May 10, 2012

Thanks! This has also been fixed in the master and stable/1.4.x branch of Django.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment