Smarter Entity Methods

Hey Elliott,

First of all, thank you for kind words about this tutorials! :)

What exactly command did you run? If you want to base on Docker configuration, you should execute "symfony composer install" instead of just "composer install", otherwise the variable won't be found. I guess the problem was in the command you ran :)

Cheers!

of course! I didn't realize you could run both composer as well as bin/console through the symfony command. it almost -- but not quite -- occurred to me that I might try that (-: thanks.

Hey Elliott,

Yeah, that's a little know fact probably, and in most cases there's literally no difference unless you start using Docker ;)

Cheers!

Hey Hanane K.!

Thanks for for the nice message ❤️❤️❤️

I was surprised when I noticed that it's not mandatory to have a "get" word at the beginning of your method to be able to use it in the TWIG (ex : getVotesString can be votesString ) , which means that when creating custom methods it's better to make them protected if we don"t want them to be accessible outside (twig).

Definitely. Better, make them private. If you don't need to access a method from outside of the class (via Twig or any other way), then make it private. I always start with private... then only make something public when I NEED to. Though, I'm a bit liberal with my getter/setter methods in my entities (I usually start with a public getter/setter for every property... and sometimes I remove methods that I don't use... but not always - I'm not strict about it).

I tried to use the doctrine annotation to set a default value, but still I get the error saying that this field (votes) can't be null, I had to set the property to Zero to make it work. Here is the syntax * @ORM\Column(type="integer",options={"default":0}) Am I missing smtg

I always set my properties to their default value anyways - I've never actually used the options={"default":0} way of doing things. There's nothing wrong it it (well, except that it's not working for you for some reason!), it's just not really needed. If you only used the options way of doing this, then it's a bit weird because your property might be null in php... but then when you save it, it will save asa 0. It's just a bit cleaner and more consistent (in my opinion) to set the property to 0... and then naturally when you save, it will save 0 to the database. So I don't know why the "options" isn't working, but I don't recommend bothering with it anyways :).

Cheers!

Hey Tomasz P.

Good catch =) Yeah of course that part of code can be much better and that's all is up to you to make it perfect!

Cheers!

Hey Name->Nick,

Fairly speaking, it's not that much important, and probably just matter of habit, but yeah, you're right, calling the getter is redundant in this case. Moreover, sometimes you even don't need a getter, so it's pointless to have it only to reference from within the class where the property is defined. Though sometimes you may have a bit extra logic in the method, and you do want to reuse it. But most of the cases, I'm for calling properties directly instead via getters within the class :)

Cheers!

Cool just making sure there wasn't some more complicated purpose behind it like doctrine having to query the database or entity persistence or something

Hey Name->Nick,

Good thing to think about, yeah :) But in this case it's much simpler, the value is just an int type ;)

Cheers!

In your migration:
`
public function up(Schema $schema): void

{
    // this up() migration is auto-generated, please modify it to your needs
    $this->addSql('ALTER TABLE question ADD votes INT');
    $this->addSql('UPDATE question SET votes = 0');
    $this->addSql('ALTER TABLE question ALTER COLUMN votes SET NOT NULL');
}

`

Hey Piotyras,

Yes, you're right, migrations generated for MySQL won't work on PostgreSQL. We usually use MySQL DB in our screencasts, so consider to generate a different migration that will work for your DB porting our migration generated for MySQL, or if you don't care about the data lose - you can execute bin/console doctrine:schema:update --force, but this trick won't fit production of course, as you do not want to lose prod data.

Thanks for sharing your solution with others!

Cheers!

Hey Shubham,

It sounds like you have a connection problem to the DB server. I'd suggest you to restart your MySQL server, and try to stop and start Symfony server as well just in case. Does it help?

Also, double check your DB schema, make sure it's valid and in sync. To check it, you can run:

$ bin/console doctrine:schema:validate

Both Mapping and Database sections are green? If it's a dev project with no real data, and you don't care about any potential data lose locally - you can try to execute:

$ bin/console doctrine:schema:update --force

To sync the DB schema and try again to see if it solves the issue. But you probably may want to write a correct migration for those executed queries to avoid data losing on production.

If nothing above helps, what exactly are you doing when see this error? Just refresh the page? What's page URL exactly?

Cheers!

Yeah it worked I restarted docker!!

Hey Shubham,

I'm happy to hear it, thanks for confirming that helps!

Cheers!

Hey Antoine R.!

> I was surprised to see that the migration did not break when adding a not nullable field to our data. It appears it's thanks to MySQL, but I didn't find informations about this behavior

Yup, you're correct, I also don't know the specifics. But I do know, for example, if you added a new "not null datetime" field, that WOULD cause a problem with MySQL.

> On the other hand, I was confused by symfony console dbal:run-sql "SELECT * FROM question" showing string(1) "0" for my new INT fields. But it's just a weird display from the command. In fact it is indeed an int. For example, a double 1.1 is displayed string(3) "1.1".

Good debugging. As i was reading this, I was also thinking "I wonder if that's just due to how it's displayed" :).

Cheers!