[FIXED] What is the symfony way to create an entry in db while migrating?

Issue

I have a DB created via migrations that is empty while I would like it to be filled.

Let's say I have a table called 'books' with 'title' and 'author'. What I would like to make sure that at least "knitting with dog hair" by "Kendall Crolius" is an entry in the DB.

I know how to do this in SQL and of course, I could simply put a script in my build process, that executes a command to check if such an entry exists and if not create it.

But what is the Symfony way to create an entry in DB while migrating/setup?

Solution

What you are looking for are data fixtures. I think the two most popular options are:

• doctrine/doctrine-fixtures-bundle
• hautelook/alice-bundle

With the former you create fixtures in code like this (taken from docs):

class AppFixtures extends Fixture
{
    public function load(ObjectManager $manager)
    {
        // create 20 products! Bam!
        for ($i = 0; $i < 20; $i++) {
            $product = new Product();
            $product->setName('product '.$i);
            $product->setPrice(mt_rand(10, 100));
            $manager->persist($product);
        }

        $manager->flush();
    }
}

You can run them using bin/console doctrine:fixtures:load.

Whereas the latter uses YAML:

App\Entity\Dummy:
    dummy_{1..10}:
        name: <name()>
        related_dummy: '@related_dummy*'

The command for adding the fixtures is: bin/console hautelook:fixtures:load

The AliceBundle has the additional benefit that it comes with integration for Faker, which lets you generate randomized data as well as static data like you suggested.

edit: The main reason for using fixture files is that you want to be independent from the underlying database. When you use an SQL script you might have to keep multiple versions for each supported DB and sometimes even need to adjust it for different versions (e.g. MySQL 5.7 vs. MySQL 8). An additional benefit is, that changes are usually easier to track in a version history in these files than in SQL, but that is debatable. Since Doctrine Fixtures are written in code you can use inspection tools to check if they are in sync with your entities, making it easier to spot when you need to change them.

That being said, if none of those benefits are an argument and you want to use an SQL script then you should keep schema changes and inserting data separate to prevent any issues. Arguably you should also not use migrations for inserting data. You either run the risk of failing the migration because an ID is already used or not rely on IDs and make it difficult to manage relations between data. You could avoid problems by doing INSERT IGNORE but then you will have a hard time identifying if your data is in the state you expect and run the risk of inconsistencies.

Answered By - dbrumann