Buy

Fixtures: Dummy Data Rocks

It's so much more fun to develop when your database has real, interesting data. We do have a way to add some fake genuses into the database, but they're not very interesting. And when we need more dummy data - like users and genus notes - it's just not going to work well.

Nope - we can do better. I'm dreaming of a system where we can quickly re-populate our local database with a really rich set of fake data, or fixtures.

Search for DoctrineFixturesBundle. This bundle is step 1 towards my dream. Copy the composer require line and paste that into the terminal. But hold on! I also want to download something else: nelmio/alice. That's just a normal PHP library, not a bundle. And it's going to make our fixtures amazing:

composer require --dev doctrine/doctrine-fixtures-bundle nelmio/alice

Conditionally Load Dev Libraries

Oh, and the --dev flag isn't too important. It means that these lines will be added to the require-dev section of composer.json:

68 lines composer.json
{
... lines 2 - 31
"require-dev": {
... lines 33 - 34
"nelmio/alice": "^2.1",
"doctrine/doctrine-fixtures-bundle": "^2.3"
},
... lines 38 - 66
}

And that's meant for libraries that are only needed for development or to run tests.

When you deploy - if you care enough - you can tell composer to not download the libraries in this section. But frankly, I don't bother.

While Composer is communicating with the mothership, copy the new bundle line and add it to AppKernel. But put it in the section that's inside of the dev if statement:

57 lines app/AppKernel.php
... lines 1 - 5
class AppKernel extends Kernel
{
public function registerBundles()
{
... lines 10 - 25
if (in_array($this->getEnvironment(), array('dev', 'test'), true)) {
... lines 27 - 30
$bundles[] = new Doctrine\Bundle\FixturesBundle\DoctrineFixturesBundle();
}
... lines 33 - 34
}
... lines 36 - 55
}

This makes the bundle - and any services, commands, etc that it gives us - not available in the prod environment. That's fine for us - this is a development tool - and it keeps the prod environment a little smaller.

Creating the Fixture Class

Anyways, this bundle gives us a new console command - doctrine:fixtures:load. When we run that, it'll look for "fixture classes" and run them. And in those classes, we'll create dummy data.

Copy the example fixture class. In AppBundle, add a DataFixtures/ORM directory. Then, add a new PHP class called - well, it doesn't matter - how about LoadFixtures. Paste the example class we so aggressively stole from the docs and update its class name to be LoadFixtures:

21 lines src/AppBundle/DataFixtures/ORM/LoadFixtures.php
... lines 1 - 2
namespace AppBundle\DataFixtures\ORM;
... lines 4 - 5
use Doctrine\Common\DataFixtures\FixtureInterface;
use Doctrine\Common\Persistence\ObjectManager;
class LoadFixtures implements FixtureInterface
{
public function load(ObjectManager $manager)
{
... lines 13 - 19
}
}

Clear out that User code. We need to create Genuses.. and we have some perfectly good code in newAction() we can steal to do that. Paste that it:

21 lines src/AppBundle/DataFixtures/ORM/LoadFixtures.php
... lines 1 - 4
use AppBundle\Entity\Genus;
... lines 6 - 8
class LoadFixtures implements FixtureInterface
{
public function load(ObjectManager $manager)
{
$genus = new Genus();
$genus->setName('Octopus'.rand(1, 100));
$genus->setSubFamily('Octopodinae');
$genus->setSpeciesCount(rand(100, 99999));
$manager->persist($genus);
$manager->flush();
}
}

The $manager argument passed to this function is the entity manager. Use it to persist $genus and don't forget the Genus use statement. Oh, and only one namespace - whoops!

I know this is not very interesting yet - stay with me. To run this, head over to the terminal and run:

./bin/console doctrine:fixtures:load

This clears out the database and runs all of our fixture classes - we only have 1. Now, head back to the list page. Here is our one random genus. So it's kind of cool... but I know - totally underwhelming. Enter Alice: she makes fixtures fun again.

Leave a comment!

  • 2017-03-21 Diego Aguiar

    Hey Dan!
    Indeed, that's the default path for fixtures, you don't have to follow that structure if you don't like it, but you will have to specify the new path in the command, like this:

    bin/console doctrine:fixtures:load --fixtures=/path/to/fixture

    Ah and thanks for mention it, we should add a note in the video :)

    Have a nice day!

  • 2017-03-21 Dan Abrey

    When you run doctrine:fixtures:load, the default path that fixture-loading classes are looked for is AppBundle/DataFixtures/ORM - that's how it knows to load the LoadFixtures class and run the load method.

    This was the first time during this course that I thought "wait, how did that happen?" without explanation, which is joyfully rare! But still I thought worth mentioning.

  • 2017-02-22 weaverryan

    Haha, cheers! :D

  • 2017-02-20 maxii123

    Enter Alice? I quick double take there. Excellent series.

  • 2016-03-17 weaverryan

    You got it :). The video for this chapter will be posted soon.

  • 2016-03-17 Michael

    Actually, it must be from here: http://symfony.com/doc/curr...

  • 2016-03-17 Michael

    Hello there,

    "Copy the example fixture class". Where do we find this?