Skip to content

Commit 0a5ec36

Browse files
committed
Merge pull request #1616 from richardmiller/adding_caching_config_to_di
Added info on using config component's ConfigCache when dumping the serv...
2 parents 1252df1 + 4e8160b commit 0a5ec36

File tree

1 file changed

+48
-5
lines changed

1 file changed

+48
-5
lines changed

components/dependency_injection/compilation.rst

Lines changed: 48 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -161,11 +161,13 @@ it::
161161
}
162162

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

170172
// ...
171173

@@ -187,3 +189,44 @@ your application::
187189
}
188190
}
189191

192+
This could be further improved by only recompiling the container in debug
193+
mode when changes have been made to its configuration rather than on every
194+
request. This can be done by caching the resource files used to configure
195+
the container in the way describe in ":doc:`/components/conf/caching`"
196+
in the config component documentation.
197+
198+
You do not need to work out which files to cache as the container builder
199+
keeps track of all the resources used to configure it, not just the configuration
200+
files but the extension classes and compiler passes as well. This means that
201+
any changes to any of these files will invalidate the cache and trigger the
202+
container being rebuilt. You just need to ask the container for these resources
203+
and use them as metadata for the cache::
204+
205+
// ...
206+
207+
// set $isDebug based on something in your project
208+
209+
$file = __DIR__ .'/cache/container.php';
210+
$containerConfigCache = new ConfigCache($file, $isDebug);
211+
212+
if (!$cache->isFresh()) {
213+
$containerBuilder = new ContainerBuilder();
214+
//--
215+
$container->compile();
216+
217+
$dumper = new PhpDumper($containerBuilder);
218+
$containerConfigCache->write(
219+
$dumper->dump(array('class' => 'MyCachedContainer')),
220+
$containerBuilder->getResources()
221+
);
222+
}
223+
224+
require_once $file;
225+
$container = new MyCachedContainer();
226+
227+
Now the cached dumped container is used regardless of whether debug mode is on or not.
228+
The difference is that the ``ConfigCache`` is set to debug mode with its second
229+
constructor argument. When the cache is not in debug mode the cached container
230+
will always be used if it exists. In debug mode, an additional metadata file
231+
is written with the timestamps of all the resource files. These are then checked
232+
to see if the files have changed, if they have the cache will be considered stale.

0 commit comments

Comments
 (0)