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

On Thu, Jul 08, 2004 at 10:50:54AM -0500, Monte Ohrt wrote:
> 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.

this would mean we should remove the touch()-call in
core.wrtie_file.php?  i have no problem with that.

people dumping compiled templates from another server should consider
turning compile_check off, anyway, not?

> 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
> >
> > 
> >
> 
> -- 
> Smarty Development Mailing List (http://smarty.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php