If you liked what you've learned so far, dive in!
Subscribe to get access to this tutorial plus
video, code and script downloads.
We're close to making the genus page dynamic - but it has a few fields that we don't have yet - like sub family, number of known species, and fun fact.
Let's add these... and be as lazy as possible when we do it! In Genus
, create the
properties first: private $subFamily
, private $speciesCount
and private $funFact
:
... lines 1 - 10 | |
class Genus | |
{ | |
... lines 13 - 27 | |
private $subFamily; | |
... lines 29 - 32 | |
private $speciesCount; | |
... lines 34 - 37 | |
private $funFact; | |
... lines 39 - 79 | |
} |
Now, just do the same thing we did before: bring up the "Code"->"Generate" menu - or
command
+N
on a Mac - select "ORM Annotation" and choose all the fields to generate
the Column
annotations above each:
... lines 1 - 10 | |
class Genus | |
{ | |
... lines 13 - 24 | |
/** | |
* @ORM\Column(type="string") | |
*/ | |
private $subFamily; | |
/** | |
* @ORM\Column(type="integer") | |
*/ | |
private $speciesCount; | |
/** | |
* @ORM\Column(type="string") | |
*/ | |
private $funFact; | |
... lines 39 - 79 | |
} |
These tries to guess the right field type - but it's not always right. speciesCount
should clearly be an integer - set it to that. For a full-list of all the built-in
Doctrine types, check their docs. The most important are string
, integer
, text
,
datetime
and float
.
Next, head to the bottom of the class to create the getter and setter methods. But wait! Realize: you might not need getters and setters for every field, so only add them if you need them. We will need them, so open "Code"->"Generate" again and select "Getters and Setters":
... lines 1 - 10 | |
class Genus | |
{ | |
... lines 13 - 49 | |
public function getSubFamily() | |
{ | |
return $this->subFamily; | |
} | |
public function setSubFamily($subFamily) | |
{ | |
$this->subFamily = $subFamily; | |
} | |
public function getSpeciesCount() | |
{ | |
return $this->speciesCount; | |
} | |
public function setSpeciesCount($speciesCount) | |
{ | |
$this->speciesCount = $speciesCount; | |
} | |
public function getFunFact() | |
{ | |
return $this->funFact; | |
} | |
public function setFunFact($funFact) | |
{ | |
$this->funFact = $funFact; | |
} | |
} |
And that's it! Create the properties, generate the annotations and generate the getters and setters if you need them.
Now, can we tell Doctrine to somehow alter the genus
table and add these columns?
Absolutely. In fact, it's one of the most incredible features of Doctrine.
In the terminal, run:
./bin/console doctrine:schema:update --dump-sql
Look familiar? That's the same command we ran before. But look: it actually
says, "ALTER TABLE genus" add sub_family
, species_count
, and fun_fact
.
This is amazing. It's able to look at the database, look at the entity, and
calculating the difference between them.
So if we were to run this with --force
, it would run that query and life would
be good. Should we do it? No! Wait, hold on!
It would work. But imagine our app was already deployed and working
on production with the first version of the genus
table. When you deploy the new
code, you'll need to run this command on production to update your table.
And that'll work 99% of the time. But sometimes, the query might not be perfect.
For example, what if I rename a property? Well, this command might drop the existing
column and add a new one. All the data from the old column would be gone! The point
is: running doctrine:schema:update
is just too dangerous on production.
But, we're going to replace it with something just as good.
Hi teacher, when I create the getters and setters (with PHPStorm), comments with @param mixed $variable is created, what does mean? can I delete them? how I can disable that in PHPStorm?
Thanks!
Hey Juan,
This's a PHPDoc annotation, check it out here: https://www.phpdoc.org/docs... . You can totally delete it if you don't need, but probably you just want tweak it a bit, for example, change "mixed" to string if you know that the field always should be a string. First of all, it helps for other developers who will work with your code, because it's kind of documentation - developers will know that the value you pass to the method is supposed to be a *string*, not object, integer, etc. The second, which I love a lot, is that IDEs like PhpStorm start hinting you types of arguments for those functions, i.e. when you call this method - PhpStorm will hint you that the argument should be a string, integer, or whatever you in that annotation and even will show a warning if the type is not corresponded that annotation. So using those annotations is good, but sometimes it's redundant when you use typehints, because in this case PhpStorm can resolve it by itself.
Cheers!
// composer.json
{
"require": {
"php": ">=5.5.9",
"symfony/symfony": "3.1.*", // v3.1.4
"doctrine/orm": "^2.5", // v2.7.2
"doctrine/doctrine-bundle": "^1.6", // 1.6.4
"doctrine/doctrine-cache-bundle": "^1.2", // 1.3.0
"symfony/swiftmailer-bundle": "^2.3", // v2.3.11
"symfony/monolog-bundle": "^2.8", // 2.11.1
"symfony/polyfill-apcu": "^1.0", // v1.2.0
"sensio/distribution-bundle": "^5.0", // v5.0.22
"sensio/framework-extra-bundle": "^3.0.2", // v3.0.16
"incenteev/composer-parameter-handler": "^2.0", // v2.1.2
"composer/package-versions-deprecated": "^1.11", // 1.11.99
"knplabs/knp-markdown-bundle": "^1.4", // 1.4.2
"doctrine/doctrine-migrations-bundle": "^1.1" // 1.1.1
},
"require-dev": {
"sensio/generator-bundle": "^3.0", // v3.0.7
"symfony/phpunit-bridge": "^3.0", // v3.1.3
"nelmio/alice": "^2.1", // 2.1.4
"doctrine/doctrine-fixtures-bundle": "^2.3" // 2.3.0
}
}
Great, this symfony3 course is better for beginners like me than the symfony2 course, i tried the symfony2 first and it was a bit fast