Skip to content

Added info on using config component's ConfigCache when dumping the serv... #1616

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Aug 4, 2012
Merged

Added info on using config component's ConfigCache when dumping the serv... #1616

Changes from 1 commit
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
879f293
Added info on using config component's ConfigCache when dumping the s…
richardmiller-zz Aug 2, 2012
4e8160b
Updated dumping DI container example to always use the dumped container
richardmiller-zz Aug 2, 2012
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
41 changes: 41 additions & 0 deletions components/dependency_injection/compilation.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -186,3 +186,44 @@ your application::
}
}

This could be further improved by only recompiling the container in debug
mode when changes have been made to its configuration rather than on every
request. This can be done by caching the resource files used to configure
the container in the way describe in ":doc:`/components/conf/caching`"
in the config component documentation.

You do not need to work out which files to cache as the container builder
keeps track of all the resources used to configure it, not just the configuration
files but the extension classes and compiler passes as well. This means that
any changes to any of these files will invalidate the cache and trigger the
container being rebuilt. You just need to ask the container for these resources
and use them as metadata for the cache::

// ...

// set $isDebug based on something in your project

$file = __DIR__ .'/cache/container.php';
$containerConfigCache = new ConfigCache($file, $isDebug);

if ($cache->isFresh()) {
require_once $file;
$container = new MyCachedContainer();
} else {
$container = new ContainerBuilder();
//--
$container->compile();

$dumper = new PhpDumper($container);
$containerConfigCache->write(
$dumper->dump(array('class' => 'MyCachedContainer')),
$container->getResources()
);
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

you could even take care of the optimized instantiation code dumped even for the first request (thus, it would make it behave more closely to others):

<?php
if (!$cache->isFresh()) {
    $containerBuilder = new ContainerBuilder()
    // dump the container here
}

require_once $file;
$container = new MyCachedContainer();

This is what is done in the Kernel for instance

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point, thanks, I have updated the example with this change.


Now the cache is used regardless of whether debug mode is on or not. The difference
is that the ``ConfigCache`` is set to debug mode with its second constructor
argument. When the cache is not in debug mode the cached container will always
be used if it exists. In debug mode, an additional metadata file is written with
the timestamps of all the resource files. These are then checked to see if the files
have changed, if they have the cache will be considered stale.