search

tel8618217223380 / prado3

Automatically exported from code.google.com/p/prado3
Other
0 stars 0 forks source link

Improvement: Proper upgrade-mechanism for Prado #217

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
Prado currently does't provide a proper and simple mechanism to upgrade an 
in-production site's code. If you try to just upgrade a codebase which is 
already active with Application::Mode set to "Performance", you'll run 
into trouble, as Prado will use partially or completely the old, pre-
parsed and cached versions of your templates, database schemas, etc. 

The document states that you can "fix" this by setting the 
Application::Mode first to "Debug" and then back to "Performance", which 
will clear the cache and let you proceed with your new templates, configs. 
However, this is actually not the case, as only those cache entries will 
get invalidated which are actually referred to in request while the 
application is running in Performance mode. That means, that unless you 
crawl your whole site while being in that mode, you will most likely still 
encounter old - now outdated - cache hits for templates in your code, 
which will cause all kinds of weird errors on your site. It's also 
ridicolous that you have to edit a text file (the application.xml) and set 
a switch back and forth to have your caches erased (which won't happen 
actually anyway, as just explained).

Therefore I propose a modification to the Prado TApplication to make such 
code/site upgrades easier. TApplication should be extended/modified to 
check for ex. the timestamp of the application.xml file at each startup, 
and if it detects any changes to the timestamp, it should clear all caches 
in use - therefore purging now probably outdated template, database, etc. 
entries.

The performance-penalty of this check should be practically zero, as Prado 
reads the application.xml file anyway at each startup. Also, there won't 
be unneccesary cache purges as application.xml file won't be ever changed 
unless there's some modification to the site itself - and if that latter 
doesn't involve modifying the application.xml file, then the file should 
be simple "touch"ed (last modification timestamp modified to current one) 
to force a proper purge of the Prado caches; this could be explained in 
the documentation. Purging all the caches will dispose of all the 
pagestates (if they're stored on server side) which have most likely 
become invalid anyway if templates have been changed - so it solves that 
problem too.

To accomplish the goals described above TApplication::onLoadState() should 
be extended with the code below:

  const CONFIG_TIMESTAMP_KEY = 'Prado:Application:ConfigTimeStamp'; // put 
this in class header

  $ts = intval($this->getGlobalState(self::CONFIG_TIMESTAMP_KEY, 0));
  $cts = intval(@filemtime($this->getConfigurationFile()));
  if ($ts!==$cts)
  {
    $app->setGlobalState(self::CONFIG_TIMESTAMP_KEY, $cts);
    $app->saveGlobals(); // save changes quick so we don't get redundant 
cache purge attempts while this is running
    foreach($app->getModules() as $module)
      if ($module instanceof TCache)
        $module->flush();
  }

This will check the timestamp of application.xml, and purge all 
application caches if the configuration file's timestamp has changed. 

Now if you upgrade your code on a production server, no more change 
between Debug and Performance modes (and the re-request of your pages) or 
manual deletion of caches neccessary. The only thing you have to do is 
to "touch" the application.xml file in the case your upgrade didn't affect 
that - and Prado will automatically reparse all your templates, database 
schemas, etc. and run properly with the updated code.

Original issue reported on code.google.com by google...@pcforum.hu on 3 Jan 2010 at 1:13

GoogleCodeExporter commented 9 years ago 
Sorry, "$app" has to be replaces with "$this" in the code above if this code is 
move 
to TApplication::onLoadState(), so the correct code is:

  const CONFIG_TIMESTAMP_KEY = 'Prado:Application:ConfigTimeStamp'; 
  // ^ put this in class header

  $ts = intval($this->getGlobalState(self::CONFIG_TIMESTAMP_KEY, 0));
  $cts = intval(@filemtime($this->getConfigurationFile()));
  if ($ts!==$cts)
  {
    $this->setGlobalState(self::CONFIG_TIMESTAMP_KEY, $cts);
    $this->saveGlobals(); 
    // ^ save changes quick so we don't get redundant cache purge attempts while 
this is running
    foreach($this->getModules() as $module)
      if ($module instanceof TCache)
        $module->flush();
  }

Original comment by google...@pcforum.hu on 3 Jan 2010 at 1:16

GoogleCodeExporter commented 9 years ago 
Why don't you use Application::Mode as "Normal"? Because this is feature of the 
Performance mode do not check the changed files.

Here is from documentation ( 
http://www.pradosoft.com/docs/manual/System/TApplication.html ):

TApplication has four modes that can be changed by setting Mode property (in 
the 
application configuration file).

=====================
Off mode will prevent the application from serving user requests.
Debug mode is mainly used during application development. It ensures the cache 
is 
always up-to-date if caching is enabled. It also allows exceptions are 
displayed with 
rich context information if they occur.
Normal mode is mainly used during production stage. Exception information will 
only 
be recorded in system error logs. The cache is ensured to be up-to-date if it 
is 
enabled.
Performance mode is similar to Normal mode except that it does not ensure the 
cache 
is up-to-date.
===============

Original comment by alex.fomenko on 7 Jan 2010 at 8:16

GoogleCodeExporter commented 9 years ago 
"Why don't you use Application::Mode as "Normal"?"
Probably because I don't want the performance penalty that comes with "Normal", 
but 
still might want to upgrade my app from time to time? 

The point is, there's no standard way in Prado to invalidate all your cached 
templates when you do an upgrade. Or if there's one, I missed it.

Original comment by google...@pcforum.hu on 7 Jan 2010 at 8:28

GoogleCodeExporter commented 9 years ago

Original comment by Christophe.Boulain@gmail.com on 11 Jan 2010 at 12:23

GoogleCodeExporter commented 9 years ago

Original comment by ctrlal...@gmail.com on 25 Jun 2012 at 1:56

GoogleCodeExporter commented 9 years ago

Original comment by ctrlal...@gmail.com on 21 Jan 2013 at 7:03

GoogleCodeExporter commented 9 years ago

Original comment by ctrlal...@gmail.com on 24 Jul 2013 at 1:46

GoogleCodeExporter commented 9 years ago 
Moved to github: https://github.com/pradosoft/prado/issues

Original comment by ctrlal...@gmail.com on 1 Oct 2013 at 10:14