Re: [SMARTY-DEV] smarty recompiling with op-code accelerators
| From: | Monte Ohrt | Date: | Thu, 08 Jul 2004 15:50:54 +0000 |
| Subject: | Re: [SMARTY-DEV] smarty recompiling with op-code accelerators | ||
| References: | 1 | Groups: | php.smarty.dev |
| Request: | Send a blank email to php-smarty-dev+get-2466@lists.php.net to get a copy of this message | ||
This isn't about dumping pre-compiled files from one server to another, that is certainly operational. The problem is when you clear the templates_c directory, the files recompile but the op-code cache does not pick up the changes (unless the original template timestamp changed.)
In theory the compiled file should be exactly the same anyways, but on occasion I see a problem with a compiled template (probably caused by NFS, I haven't tracked that down yet), and I need that compiled file cleared and recompiled. It would be nice if the op-code cache wasn't in the equation.
IMHO, the compiled Smarty files should get a new timestamp, not the same one as the originating template file. If you dump template files from another server, it should be operational procedure to touch them to be sure Smarty picks up the changes.
boots wrote:
--- Mark Rogers <mark@quarella.co.uk> wrote:IMHO we shouldn't really be telling the OS that the file hasn't changed when it has, which appears to be what we're doing here - presumably that also has implications for backups (if anyone is backing up templates_c, which I'm sure some people are), and doubtless other situations which (like the op-code cache) aren't obvious until they bite. Should we instead be looking for a better way for Smarty to determine that the file matches the template and doesn't need recompiling?Again, its operational, isn't it? When "dumping" pre-compiled files from one server to another, instead of overwriting an existing templates_c dir, create a new one and have the application point to that one instead. No conflicts. I don't see why it should be Smarty's responsibility if timestamps (that were created elsewhere) are not consisitent on the local server or to determine the capabilities of the opcode caches, etc. xo boots