I may add another mistake seen in the documentation of SF 6.0 concerning the configuration of Validation : https://symfony.com/doc/6.0/reference/configuration/framework.html#validation

But the real default value is ['config/validator/'].

@srbetasign You should report this here: https://github.com/symfony/symfony-docs.

another small thing from book I've just spent a long time on -- needed to sudo apt-get install php-pgsql for the command symfony console make:entity Conference otherwise displayed driver errors

This dependency is listed as the ones you need to install in chapter 1: https://symfony.com/doc/current/the-fast-track/en/1-tools.html#php

This dependency is listed as the ones you need to install in chapter 1: https://symfony.com/doc/current/the-fast-track/en/1-tools.html#php

ah, i'm so sorry. don't know how i missed this

Can you share the full output?

@fabpot I found the error and it was because of the database URL env variable which was empty. Thanks for your reply

Well, the second part (after the and) describes what happens when this method is called.

Sure, you are right, the code and the text are in sync. My bad.
The text mentions the setCreatedAtValue() itself, which, somehow I just mixed with the entity's setCreatedAt(\DateTimeImmutable $createdAt): self method.

However, still, perhaps its a better way to use setCreatedAt() internal setter to set the current DateTime, instead of directly assigning the value? Like this:

#[ORM\PrePersist]
public function setCreatedAtValue()
{
    $this->setCreatedAt(new \DateTimeImmutable());
}

there is no benefit to that. Accessing the private property directly is perfectly fine (thus, there is no reason to even keep a setCreatedAt method in the entity IMO)

I agree, in this case, there is no difference. However, in general, it's better practice to encapsulate property assigning in a method, for cases when you need to manipulate value before assigning every time.