[SMARTY] Should $this->compile_check logic check the timestamp of parent & included php files?
Robert V. Zwink 29 May 2002 20:11:59
I am considering adding functionality to our implementation of Smarty, and I wanted to know what the disadvantages might be.
The functionality I want to add is that when the parent php file, or the php files included with include() or require_once(), have been updated, Smarty would automatically expire the related cache files. My reasoning is that when one of our developers updates a php page, or a file that is typically included, the Smarty cache persists because the HTML template has not been updated.
We don't necessarily want to delete _all_ of the cache when we send a change to our development servers. If I add functionality to check the timestamp of parent php files (and included files), the affected cached will automatically be regenerated.
I'm considering using the php function get_included_files() during the $this->compile_check logic to get the last modified timestamp of all php (and included files) when testing whether not to expire the cache.
Has this been addressed in the past? Is there a reason why the logic only checks the timestamp of the included templates and not the actual php pages? Do most people just purge the entire cache when php on the site is updated?
Just curious, thanks for your time and a wonderful product.
Instead of adding functionality you could create a plugin for use with {insert} to include files. The output of an insert is not cached. This would be a slower solution, since you loose the caching on anything coming from those included scripts, but you could just use this technique until your includes are in a more stable state and then go back to using include.
It's one way anyway.
Ben Godfrey
On Tuesday, May 28, 2002, at 07:42 PM, Robert V. Zwink wrote:
I am considering adding functionality to our implementation of > Smarty, and I> wanted to know what the disadvantages might be.>
The functionality I want to add is that when the parent php > file, or the php> files included with include() or require_once(), have been > updated, Smarty> would automatically expire the related cache files. My > reasoning is that> when one of our developers updates a php page, or a file that > is typically> included, the Smarty cache persists because the HTML template > has not been> updated.>
We don't necessarily want to delete _all_ of the cache when we > send a change> to our development servers. If I add functionality to check > the timestamp> of parent php files (and included files), the affected cached will> automatically be regenerated.>
I'm considering using the php function get_included_files() during the> $this->compile_check logic to get the last modified timestamp > of all php> (and included files) when testing whether not to expire the cache.>
Has this been addressed in the past? Is there a reason why the > logic only> checks the timestamp of the included templates and not the > actual php pages?> Do most people just purge the entire cache when php on the site > is updated?>
Just curious, thanks for your time and a wonderful product.>
Thanks for your reply. Our include files don't output HTML, they contain information about our database queries, along with connection information. For example if I change the database I connect to within an include file, the smarty cache will persist until I manually remove it. We are not using the smarty {include}, but instead php's include().
$smarty = new Smarty; if($smarty->is_cached("template.html", $product_id)){ $smarty->display("template.html", $product_id); } ?>
Right now if the template "template.html" is updated, the is_cached() method will return false, and the cache will be destroyed.
But if "Smarty.class.php", "Another.class.php", or "template.php" is updated the is_cached() method will still return true because Smarty currently does not test the timestamp of the parent or included php files to determine if the cache should be expired.
My solution to this is to modify the is_cached method to take into account the parent script and all supporting include files timestamp. This is the functionality I want to add, I wonder what the disadvantages might be. This may have been talked about previously and I wonder why is_cached only tests the template timestamp and not the parent php documents. Thanks for any help.
-----Original Message----- From: Ben Godfrey [mailto:ben@hypothetical.co.uk] Sent: Wednesday, May 29, 2002 9:44 AM To: smarty-general@lists.php.net Subject: Re: [SMARTY] Should $this->compile_check logic check the timestamp of parent & included php files?
Rob,
Instead of adding functionality you could create a plugin for use with {insert} to include files. The output of an insert is not cached. This would be a slower solution, since you loose the caching on anything coming from those included scripts, but you could just use this technique until your includes are in a more stable state and then go back to using include.
It's one way anyway.
Ben Godfrey
On Tuesday, May 28, 2002, at 07:42 PM, Robert V. Zwink wrote:
I am considering adding functionality to our implementation of> Smarty, and I> wanted to know what the disadvantages might be.>
The functionality I want to add is that when the parent php> file, or the php> files included with include() or require_once(), have been> updated, Smarty> would automatically expire the related cache files. My> reasoning is that> when one of our developers updates a php page, or a file that> is typically> included, the Smarty cache persists because the HTML template> has not been> updated.>
We don't necessarily want to delete _all_ of the cache when we> send a change> to our development servers. If I add functionality to check> the timestamp> of parent php files (and included files), the affected cached will> automatically be regenerated.>
I'm considering using the php function get_included_files() during the> $this->compile_check logic to get the last modified timestamp> of all php> (and included files) when testing whether not to expire the cache.>
Has this been addressed in the past? Is there a reason why the> logic only> checks the timestamp of the included templates and not the> actual php pages?> Do most people just purge the entire cache when php on the site> is updated?>
Just curious, thanks for your time and a wonderful product.>
At 10:41 29/05/02 -0400, Robert V. Zwink wrote:>But if "Smarty.class.php", "Another.class.php", or "template.php" is updated>the is_cached() method will still return true because Smarty currently does>not test the timestamp of the parent or included php files to determine if>the cache should be expired.
But that's the correct behaviour. What's contained in your PHP files should have no relevance to what's cached. If the Smarty class changes then it shouldn't clear the templates as it has nothing much to do with the HTML output.
On Wed, 29 May 2002, Robert V. Zwink wrote:> For the most part when I change a MySQL query within a PHP page it will have> an impact on the generated Smarty output. If I change the MySQL query> within an included php page it can also affect the Smarty output. We needed> to change a MySQL SELECT statement to only select LEFT(field, 255) for> performance reasons. This had an effect on records with fields longer than> 255.>
I might find a bug that when fixed could affect the generated output. The> problem now is that when the bug is fixed, the cache persists. It becomes> possible to have Smarty generated output of a php script persist even though> the script would no longer generate the same output. We don't neccesarily> want to purge all of the cached files when we update a page, we only want to> destory the cached output that could have been affected by the change.>
If we change a php page that generates output that is cached why would we> not want to update the cache when the php files are updated? The Smarty> class example is perfect, if I update the smarty class file, why wouldn't I> want to update all affected cache. They might end up being exactly the> same, but if there is a chance they would be different, it seems ideal to> have them updated immediately.
You can generate a different cache ID based on your PHP file. For example, you could do md5() on the source of your PHP file and then use that as part of the cache ID.
"Are you implying that cryptic pointer arithmetic isn't just as crystal clear as mere simple functions? What kind of a C programmer are you?" -- Zeev Suraski
What's contained in your PHP files> should have no relevance to what's cached.
For the most part when I change a MySQL query within a PHP page it will have an impact on the generated Smarty output. If I change the MySQL query within an included php page it can also affect the Smarty output. We needed to change a MySQL SELECT statement to only select LEFT(field, 255) for performance reasons. This had an effect on records with fields longer than 255.
I might find a bug that when fixed could affect the generated output. The problem now is that when the bug is fixed, the cache persists. It becomes possible to have Smarty generated output of a php script persist even though the script would no longer generate the same output. We don't neccesarily want to purge all of the cached files when we update a page, we only want to destory the cached output that could have been affected by the change.
If we change a php page that generates output that is cached why would we not want to update the cache when the php files are updated? The Smarty class example is perfect, if I update the smarty class file, why wouldn't I want to update all affected cache. They might end up being exactly the same, but if there is a chance they would be different, it seems ideal to have them updated immediately.
-Rob Z.
-----Original Message----- From: Peter Bowyer [mailto:reywob@f2s.com] Sent: Wednesday, May 29, 2002 10:51 AM To: Robert V. Zwink; Ben Godfrey; smarty-general@lists.php.net Subject: RE: [SMARTY] Should $this->compile_check logic check the timestamp of parent & included php files?
At 10:41 29/05/02 -0400, Robert V. Zwink wrote:>But if "Smarty.class.php", "Another.class.php", or "template.php" is updated>the is_cached() method will still return true because Smarty currently does>not test the timestamp of the parent or included php files to determine if>the cache should be expired.
But that's the correct behaviour. What's contained in your PHP files should have no relevance to what's cached. If the Smarty class changes then it shouldn't clear the templates as it has nothing much to do with the HTML output.
To do this within the php script I would need to read in the contents of get_included_files(), then md5_file() each element in the array. Then concat the output for my cache id. I suppose I could also read in the contents of get_included_files() then just get the modified timestamp using filemtime(). Might make an interesting benchmark. Either one seems like the correct method.
Thanks for your response. I sincerely appreciate the support this forum offers. I will add the above method to each php file on the site when generating the cache id, instead of making a change to the compile_check logic.
Thanks! Robert Zwink
-----Original Message----- From: Andrei Zmievski [mailto:andrei@ispi.net] Sent: Wednesday, May 29, 2002 11:13 AM To: Robert V. Zwink Cc: smarty-general@lists.php.net Subject: Re: [SMARTY] Should $this->compile_check logic check the timestamp of parent & included php files?
On Wed, 29 May 2002, Robert V. Zwink wrote:> For the most part when I change a MySQL query within a PHP page it will have> an impact on the generated Smarty output. If I change the MySQL query> within an included php page it can also affect the Smarty output. We needed> to change a MySQL SELECT statement to only select LEFT(field, 255) for> performance reasons. This had an effect on records with fields longer than> 255.>
I might find a bug that when fixed could affect the generated output. The> problem now is that when the bug is fixed, the cache persists. It becomes> possible to have Smarty generated output of a php script persist even
though> the script would no longer generate the same output. We don't neccesarily> want to purge all of the cached files when we update a page, we only want
destory the cached output that could have been affected by the change.>
If we change a php page that generates output that is cached why would we> not want to update the cache when the php files are updated? The Smarty> class example is perfect, if I update the smarty class file, why wouldn't
want to update all affected cache. They might end up being exactly the> same, but if there is a chance they would be different, it seems ideal to> have them updated immediately.
You can generate a different cache ID based on your PHP file. For example, you could do md5() on the source of your PHP file and then use that as part of the cache ID.
"Are you implying that cryptic pointer arithmetic isn't just as crystal clear as mere simple functions? What kind of a C programmer are you?" -- Zeev Suraski
At 11:16 29/05/02 -0400, Robert V. Zwink wrote:>I might find a bug that when fixed could affect the generated output. The>problem now is that when the bug is fixed, the cache persists. It becomes>possible to have Smarty generated output of a php script persist even though>the script would no longer generate the same output. We don't neccesarily>want to purge all of the cached files when we update a page, we only want to>destory the cached output that could have been affected by the change.
Make a simple file containing the following code: <?php require_once 'Smarty/Smarty.php'; $smarty = new Smarty; $smarty->clear_compiled_tpl(); $smarty->clear_all_cache(); ?>
Then, every time you make a change just run this to remove the compiled templates + cache. Of course you don't need to remove the compiled templates if compile_check = On, but as I don't know your setup then I've included it.
![[SMARTY] Should $this->compile_check logic check the timestamp of parent & included php files?](http://qaix.com/i/logo_new.gif){kind=logo}
