During the analysis of Symfony projects, SensioLabsInsight tries to boot your application to analyze the content of your service container and compute violations about it.
Booting a Symfony application does not usually require a database, and requireing one is not disrable. Even if SensioLabsInsight boots your application kernel to analyze it, theoretically, a local database should not be required.
Yet, in some cases you can see "Dependencies cannot be installed" or
"SensioLabsInsight was not able to boot your Symfony application" error.
The reason is that SensioLabsInsight always try to install and boot your
application before analyzing it. When installing your project's dependencies,
composer install command is executed. In turn, this command executes the
cache:clear command, which tries to boot the kernel of your application.
If your application tries to connect to a database when booting its kernel, SensioLabsInsight won't be able to boot it and your project will only be partially analyzed.
You cannot connect to a local database when running code analysis. In fact, this is even considered as a bad practice. The reason is that it implies that every single kernel boot (so every single request or command) will make a connection even if it's not used afterwards. This increases the load on the database for no use, can degrade performance, or can even disallow simple maintenance tasks like clearing the cache if a connectivity issue arise.
If you only require a database server for the
composer install step, as of
today, several database engines are available out of the box: MongoDB,
Redis, and Memcached; and you can install other by using
then need to start it using the pre_composer_script section of the
As SensioLabsInsight analysis are done in two steps, starting a server in the pre_composer_script section won't make it available for the analysis and kernel boot.