Download the PHP package vkr/fixture-loader-bundle without Composer

Overview

This bundle simplifies loading of fixtures for applications that use Doctrine Fixtures and MySQL. It introduces sensible defaults and provides a couple of console commands that replace and provides an opportunity to write your own commands and rulesets. It also deals with an old and well-known bug that concerns truncating the DB that contains foreign keys.

Please note that this bundle contains some non-ANSI-compatible MySQL code and therefore cannot be used with other DB drivers supported by Doctrine DBAL.

Configuration

This bundle accepts two configuration parameters, both of which are optional and located under key.

sets the path relative to Symfony root directory for the parent directory to where your fixture directories are located. For example, if you have and directories as children to , then this setting should be set to . The default value is .

setting needs to be used if you create your own type manager. It should be equal to service alias as set in . The default value is .

Composition

FixturesLoader

At the heart of this bundle lies a service called . Its only public method accepts three arguments. The first argument corresponds to the directory name of the fixture subset relative to setting. The second argument is a callable that is responsible for displaying the logging information to the console. This callable can be set in the method of your command class and should use variable of Symfony Console component. The third argument is a boolean that purges the database (not the table!) if false or keeps the existing data if true.

Unlike the default Doctrine Fixtures load command, this service is opinionated in the following manner:

1) If the third argument is false, the data is always purged, not deleted, that allows client coders to rely upon auto-incremented columns in fixtures. 2) Foreign key checks are always disabled while purging to suppress error messages in younger versions of MySQL.

If the directory specified as the first argument is empty or does not exist, no errors will be thrown and, given that the third argument is false, the data will be purged anyway.

FixtureTypeManager

This simple class defines the ruleset for various console fixture loaders. The default version of this class defines three public methods.

accepts a callable as its argument and passes it on to . This method must be called before any other method.

handles command, it loads fixtures from directory and purges the DB if option is set.

handles command. It does the following: 1) purges the DB 2) loads fixtures from directory if they exist 3) loads fixtures from .

This class can be extended to include your own commands and rulesets.

Console commands

Two commands are shipped with this bundle.

is designed to set static data that is needed for the application to work and is unlikely to change in the future, such as list of supported languages. It loads fixtures from directory and it will purge the DB if called with option (meaning that it will not purge anything by default). It is important to understand that if this option is not set, target tables will not be purged, which can lead to unexpected behavior. It is recommended to truncate the data from target tables manually in your fixture classes.

is designed for restoring the test database data for functional tests. It purges the database, then tries to load fixtures (that allows to avoid the overhead of running ), then loads fixtures from directory. In order to be foolproof, this command will error out if used without option. It allows to define file with its own connection data that will be used for purgeable test DB while keeping the main DB safe. If one test environment is not enough for you, you can create additional environments that contain the word in their names and use this command in this manner: .

Both commands can work with non-default entity managers by providing option.

Customization

Custom type managers

If you want to define your own fixture-loading commands or override the behavior of built-in commands, you can define your own classes that extend and add public methods or override existing methods. It is recommended to call from all new methods.

Custom commands

You can add your own console commands that will use and . The easiest way to do this is to copy one of the built-in commands and modify it. It is recommended to include these lines in your method: