Re: [SMARTY-DEV] smarty recompiling with op-code accelerators

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 <[email protected]> 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
>
>  
>