Foundry: Always Pass a Factory Instance to a Relation

Hey Tristan N.!

Hmm. This might not be a big deal. With Mysql & Docker, iirc, I think Docker might not create the actual "database" for you. And so you can create it via symfony console doctrine:database:create. The fact that you see "Unknown database" means that it is successfully connected to MySQL.

But, in addition: I had something strange: when I asked: "docker-compose ps", I hadn't the same table!

Hmm. I think there are 2 things happening here:

1) The different "headers" on the table suggest that you may have just upgraded to a newer version of Doctrine with new headers. When I run docker-compose ps, I see the same new columns that you see (e.g. NAME | COMMAND | SERVICE, etc).

2) The exposed port was 50153 before and it's now 49363. That's expected: each time you restart Docker, it will bind port 3306 of the container to a different, random port on your host machine. But that's ok: the symfony binary automatically reads the random port and uses it when it adds the DATABASE_URL environment variable.

Let me know if this helps!

Cheers!

Yes, it works! Thank you, Ryan ^^

Hey Ruslan,

It depends on, if you store those data in a special table or use scalar values for them. You could create a special table where you will store the statuses for example, and then you will do exactly what we do in this screencast, i.e. make a DB relation between a specific status and e.g. an Order entity. But usually such things as statuses we save as scalar values, i.e. you create a new "varchar" column for Order entity called "status" and set a scalar value to it, e.g. "paid". And all possible statuses we write as constants on an entity. Then, you will be able to create a method that will return all possible statuses, e.g. getSupportedStatuses():

Order
{
    public const STATUS_NEW = 'new';
    public const STATUS_PAID = 'paid';

    // ...

    public static function getSupportedStatuses(): array
    {
        return [
            self::STATUS_NEW,
            self::STATUS_PAID,
        ]
    }
}

Then, in the factory, you can leverage faker to get a random element of the array e.g. " $faker->randomElement(Order:: getSupportedStatuses());"

Or you can just hardcode the specific status by default. Or create a special method on the factory that will help you to set a specific status on the entity that you will pass as an argument.

I hope this helps!

Cheers!

Thank you for clarification. For "scalar" is clear.
But for still unclear , if I need Country (table of all countries) - it's fixed dictionary.
How will you do in that situation? Will you fill data in migration or write Fixture ?

Hey Ruslan,

Ah, ok! Well, migrations and fixtures are totally different things :) Migrations are basically used to "migrate" DB changes on production without losing real data. If you want to pre-fill your local database with some dummy data so it don't be just an empty DB - fixtures are exactly what you need.

But regarding your question, in the AppFixtures where you create all your fixtures fetch a real Country entity object/objects you need from the DB via entity manager and set them, something like we do in this course:

class AppFixtures extends Fixture
{
    public function load(ObjectManager $manager)
    {
        // Fetch the Country entity object here
        $country = $manager->getRepository(Country::class)->find(1);

        QuestionTagFactory::createMany(100, function() {
            return [
                'tag' => TagFactory::random(),
                'question' => QuestionFactory::random(),
                'country' => $country, // And set it here
            ];
        });

       // ...
    }
}

Something like this. I hope this helps!

Cheers!

Hey Abdeljabar T.

What if you upload a set of images into your public directory and then, you just have a list of their paths in your fixtures that you will assign randomly to your Image objects?

Cheers!

Hey Mepcuk!

Ha, fair enough :). The goal of the previous chapter is probably "Having fake database data is great, and Foundry make it easy, and here is how you use Foundry with Doctrine relations". This chapter really just focuses on covering one edge-case when people use Foundry with relations (that's this part here: https://symfonycasts.com/sc... ).

Cheers!