|
it is the TypeCollection that makes use of the config_version. If no script is configured it uses the current time (at the point when someone asks the TypeCollection for its version). Thus, when something decides to evict the type collection (before directory environments when a watched file being updated, and after directory environments, only when the environment times out) the type collection gets a new version. With directory environments there is no watching of files.
Environment caching does not take config_version into account afaict - it is only based on the "time to live" and the creation time of the environment. Maybe it should also run the config_version script.
I could be wrong, and that there are other code paths that make use of the script/version. There is no good specification, and spec tests does not make it clear what the expected behavior is.
The business feature "auditability" is quite complex as it implies that there is a guarantee (as in 100% certain) that the produced content has a particular version. Due to the asynchronous nature and that any file can change at any time makes it is impossible to guarantee. Thus, if we simply reevaluate the config_version script for each environment cache expiry check (happens for each compilation), we would create a new version every time if there is no script (since it is time base by default), and it would be as good as the script checking if there is a new version otherwise. Since there is no locking, as soon as the script has been evaluated a file may change and that would go unnoticed until the next request. In order to work correctly with a guarantee worth anything, we would need more drastic changes as in having a "walled garden" into which changes are "pushed" (i.e. the server knows exactly when changes occur without having to run extremely slow (lots of file stats) and using a myriad of locks). A simple "a file changed"-strategy is not good enough as it can cause problems with using an (undetected) mix of versions.
|
