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 all commits
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
53 changes: 48 additions & 5 deletions components/dependency_injection/compilation.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -160,11 +160,13 @@ it::
}

You will now get the speed of the PHP configured container with the ease of using
configuration files. In the above example you will need to delete the cached
container file whenever you make any changes. Adding a check for a variable that
determines if you are in debug mode allows you to keep the speed of the cached
container in production but getting an up to date configuration whilst developing
your application::
configuration files. Additionally dumping the container in this way further optimizes
how the services are created by the container.

In the above example you will need to delete the cached container file whenever
you make any changes. Adding a check for a variable that determines if you are
in debug mode allows you to keep the speed of the cached container in production
but getting an up to date configuration whilst developing your application::

// ...

Expand All @@ -186,3 +188,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()) {
$containerBuilder = new ContainerBuilder();
//--
$container->compile();

$dumper = new PhpDumper($containerBuilder);
$containerConfigCache->write(
$dumper->dump(array('class' => 'MyCachedContainer')),
$containerBuilder->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.


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

Now the cached dumped container 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.