If you liked what you've learned so far, dive in!
Subscribe to get access to this tutorial plus
video, code and script downloads.
With a Subscription, click any sentence in the script to jump to that part of the video!
Login SubscribeWe're creating our dummy article data in a really... uh... dummy way: with a, sort of, "secret" endpoint that creates an almost-identical article, each time we go there:
... lines 1 - 10 | |
class ArticleAdminController extends AbstractController | |
{ | |
/** | |
* @Route("/admin/article/new") | |
*/ | |
public function new(EntityManagerInterface $em) | |
{ | |
$article = new Article(); | |
$article->setTitle('Why Asteroids Taste Like Bacon') | |
->setSlug('why-asteroids-taste-like-bacon-'.rand(100, 999)) | |
->setContent(<<<EOF | |
Spicy **jalapeno bacon** ipsum dolor amet veniam shank in dolore. Ham hock nisi landjaeger cow, | |
lorem proident [beef ribs](https://baconipsum.com/) aute enim veniam ut cillum pork chuck picanha. Dolore reprehenderit | |
labore minim pork belly spare ribs cupim short loin in. Elit exercitation eiusmod dolore cow | |
**turkey** shank eu pork belly meatball non cupim. | |
Laboris beef ribs fatback fugiat eiusmod jowl kielbasa alcatra dolore velit ea ball tip. Pariatur | |
laboris sunt venison, et laborum dolore minim non meatball. Shankle eu flank aliqua shoulder, | |
capicola biltong frankfurter boudin cupim officia. Exercitation fugiat consectetur ham. Adipisicing | |
picanha shank et filet mignon pork belly ut ullamco. Irure velit turducken ground round doner incididunt | |
occaecat lorem meatball prosciutto quis strip steak. | |
Meatball adipisicing ribeye bacon strip steak eu. Consectetur ham hock pork hamburger enim strip steak | |
mollit quis officia meatloaf tri-tip swine. Cow ut reprehenderit, buffalo incididunt in filet mignon | |
strip steak pork belly aliquip capicola officia. Labore deserunt esse chicken lorem shoulder tail consectetur | |
cow est ribeye adipisicing. Pig hamburger pork belly enim. Do porchetta minim capicola irure pancetta chuck | |
fugiat. | |
EOF | |
); | |
// publish most articles | |
if (rand(1, 10) > 2) { | |
$article->setPublishedAt(new \DateTime(sprintf('-%d days', rand(1, 100)))); | |
} | |
$article->setAuthor('Mike Ferengi') | |
->setHeartCount(rand(5, 100)) | |
->setImageFilename('asteroid.jpeg') | |
; | |
$em->persist($article); | |
$em->flush(); | |
return new Response(sprintf( | |
'Hiya! New Article id: #%d slug: %s', | |
$article->getId(), | |
$article->getSlug() | |
)); | |
} | |
} |
Honestly, it's not great for development: every article on the homepage pretty much looks the same.
Yep, our dummy data sucks. And, that's important! If we could load a rich set of random data easily, we could develop and debug faster.
To help with this, we'll use a great library called DoctrineFixturesBundle... but with our own spin to make things really fun.
First let's get it installed. Find your terminal and run
composer require orm-fixtures:3.0.2 --dev
And yep, this is a Flex alias, and we're using --dev
because this tool will help us load fake data for development... which is not something we need in our production code. If you've ever accidentally replaced the production database with dummy data... you know what I mean.
Perfect! When it finishes, generate our first fixture class by running:
php bin/console make:fixtures
Call it ArticleFixtures
. It's fairly common to have one fixture class per entity, or sometimes, per group of entities. And... done!
Go check it out: src/DataFixtures/ArticleFixtures.php
:
... lines 1 - 2 | |
namespace App\DataFixtures; | |
use Doctrine\Bundle\FixturesBundle\Fixture; | |
use Doctrine\Common\Persistence\ObjectManager; | |
class ArticleFixtures extends Fixture | |
{ | |
public function load(ObjectManager $manager) | |
{ | |
// $product = new Product(); | |
// $manager->persist($product); | |
$manager->flush(); | |
} | |
} |
The idea behind fixtures is dead simple: step (1) we write code to create and save objects, and then step (2), we run a new console command that executes all of our fixture classes.
Open ArticleAdminController
: let's start stealing some code! Copy all of our dummy article code, go back to the fixture class, and paste! We need to re-type the e
on Article
and hit tab so that PhpStorm adds the use
statement for us on top:
... lines 1 - 4 | |
use App\Entity\Article; | |
... lines 6 - 8 | |
class ArticleFixtures extends Fixture | |
{ | |
public function load(ObjectManager $manager) | |
{ | |
$article = new Article(); | |
... lines 14 - 48 | |
} | |
} |
Then, at the bottom, the entity manager variable is called $manager
:
... lines 1 - 8 | |
class ArticleFixtures extends Fixture | |
{ | |
public function load(ObjectManager $manager) | |
{ | |
$article = new Article(); | |
... lines 14 - 45 | |
$manager->persist($article); | |
$manager->flush(); | |
} | |
} |
Back in the controller, just put a die('todo')
for now:
... lines 1 - 10 | |
class ArticleAdminController extends AbstractController | |
{ | |
/** | |
* @Route("/admin/article/new") | |
*/ | |
public function new(EntityManagerInterface $em) | |
{ | |
die('todo'); | |
... lines 19 - 24 | |
} | |
} |
Someday, we'll create a proper admin form here.
And... that's it! It's super boring and it only creates one article... but it should work! Try it: find your terminal and run a new console command:
php bin/console doctrine:fixtures:load
This will ask if you want to continue because - important note! - the command will empty the database first, and then load fresh data. Again, not something you want to run on production... not saying I've done that before.
When it finishes, find your browser, and refresh. It works!
But... come on! We're going to need more than one article! How can we create multiple? First, we're going to do it the easy... but, kinda boring way. A for
loop! Say: for $i = 0; $i < 10;
$i++. And, all the way at the bottom, add the ending curly brace. We need to call persist()
in the loop, but we only need to call flush()
once at the end.
Cool! Try it again:
php bin/console doctrine:fixtures:load
Then, refresh! Awesome! Except that the articles are still totally boring and identical... we'll talk about that in the next chapter.
But first, let me show you a cooler way to create multiple articles. In the DataFixtures
directory, create a new class called BaseFixture
. Make it abstract, and extend the normal class that all fixtures extend... so... Fixture
:
... lines 1 - 2 | |
namespace App\DataFixtures; | |
use Doctrine\Bundle\FixturesBundle\Fixture; | |
... lines 6 - 7 | |
abstract class BaseFixture extends Fixture | |
{ | |
... lines 10 - 20 | |
} |
Here's the idea: this will not be a fixture class that the bundle will execute. Instead, it will be a base class with some cool helper methods. To start, copy the load()
method and implement it here. Re-type ObjectManager
to get its use
statement:
... lines 1 - 2 | |
namespace App\DataFixtures; | |
... lines 4 - 5 | |
use Doctrine\Common\Persistence\ObjectManager; | |
abstract class BaseFixture extends Fixture | |
{ | |
... lines 10 - 14 | |
public function load(ObjectManager $manager) | |
{ | |
... lines 17 - 19 | |
} | |
} |
Oh, ObjectManager
is an interface implemented by EntityManager
, it's not too important: just think "this is the entity manager".
Next, and this won't make sense yet, create a private $manager
property, and set it inside the load()
method:
... lines 1 - 7 | |
abstract class BaseFixture extends Fixture | |
{ | |
... line 10 | |
private $manager; | |
... lines 12 - 14 | |
public function load(ObjectManager $manager) | |
{ | |
$this->manager = $manager; | |
... lines 18 - 19 | |
} | |
} |
Finally, create an abstract protected function
called loadData()
with that same ObjectManager
argument:
... lines 1 - 7 | |
abstract class BaseFixture extends Fixture | |
{ | |
... lines 10 - 12 | |
abstract protected function loadData(ObjectManager $manager); | |
... lines 14 - 20 | |
} |
Back in load()
, call this: $this->loadData($manager)
:
... lines 1 - 7 | |
abstract class BaseFixture extends Fixture | |
{ | |
... lines 10 - 14 | |
public function load(ObjectManager $manager) | |
{ | |
... lines 17 - 18 | |
$this->loadData($manager); | |
} | |
} |
So far, this doesn't do anything special. Back in ArticleFixtures
, extend the new BaseFixture
instead. I'll also cleanup the extra use
statement:
... lines 1 - 4 | |
use App\Entity\Article; | |
use Doctrine\Common\Persistence\ObjectManager; | |
class ArticleFixtures extends BaseFixture | |
{ | |
... lines 10 - 48 | |
} |
Now, instead of implementing load()
, implement loadData()
and make it protected:
... lines 1 - 7 | |
class ArticleFixtures extends BaseFixture | |
{ | |
public function loadData(ObjectManager $manager) | |
{ | |
... lines 12 - 47 | |
} | |
} |
And... yea! The fixture system will call load()
on BaseFixture
, that will call loadData()
on ArticleFixtures
and... well... everything will work exactly like before.
So... why did we just do this? Go back to the BaseFixture
class and, at the bottom, I'm going to paste in a little method that I created:
... lines 1 - 7 | |
abstract class BaseFixture extends Fixture | |
{ | |
... lines 10 - 21 | |
protected function createMany(string $className, int $count, callable $factory) | |
{ | |
for ($i = 0; $i < $count; $i++) { | |
$entity = new $className(); | |
$factory($entity, $i); | |
$this->manager->persist($entity); | |
// store for usage later as App\Entity\ClassName_#COUNT# | |
$this->addReference($className . '_' . $i, $entity); | |
} | |
} | |
} |
Oh, and to make PhpStorm happy, at the top, add some PHPDoc that the $manager
property is an ObjectManager
instance:
... lines 1 - 5 | |
use Doctrine\Common\Persistence\ObjectManager; | |
abstract class BaseFixture extends Fixture | |
{ | |
/** @var ObjectManager */ | |
private $manager; | |
... lines 12 - 32 | |
} |
Anyways, say hello to createMany()
! A simple method that we can call to create multiple instances of an object. Here's the idea: we call createMany()
and pass it the class we want to create, how many we want to create, and a callback method that will be called each time an object is created. That'll be our chance to load that object with data.
Basically, it does the for
loop for us... which is not a huge deal, except for two nice things. First, it calls persist()
for us, so we don't have to:
... lines 1 - 7 | |
abstract class BaseFixture extends Fixture | |
{ | |
... lines 10 - 21 | |
protected function createMany(string $className, int $count, callable $factory) | |
{ | |
for ($i = 0; $i < $count; $i++) { | |
... lines 25 - 27 | |
$this->manager->persist($entity); | |
... lines 29 - 30 | |
} | |
} | |
} |
Ok, cool, but not amazing. But, this last line is cool:
... lines 1 - 7 | |
abstract class BaseFixture extends Fixture | |
{ | |
... lines 10 - 21 | |
protected function createMany(string $className, int $count, callable $factory) | |
{ | |
for ($i = 0; $i < $count; $i++) { | |
... lines 25 - 28 | |
// store for usage later as App\Entity\ClassName_#COUNT# | |
$this->addReference($className . '_' . $i, $entity); | |
} | |
} | |
} |
It won't matter yet, but in a future tutorial, we will have multiple fixtures classes. When we do, we will need to be able to reference objects created in one fixture class from other fixture classes. By calling addReference()
, all of our objects are automatically stored and ready to be fetched with a key that's their class name plus the index number.
The point is: this is going to save us some serious work... but not until the next tutorial.
Back in ArticleFixtures
, use the new method: $this->createMany()
passing it Article::class
, 10, and a function:
... lines 1 - 7 | |
class ArticleFixtures extends BaseFixture | |
{ | |
public function loadData(ObjectManager $manager) | |
{ | |
$this->createMany(Article::class, 10, function(Article $article, $count) { | |
... lines 13 - 43 | |
}); | |
... lines 45 - 46 | |
} | |
} |
This will have two args: the Article
that was just created and a count of which article this is. Inside the method, we can remove the $article = new Article()
, and instead of a random number on the slug, we can use $count
:
... lines 1 - 7 | |
class ArticleFixtures extends BaseFixture | |
{ | |
public function loadData(ObjectManager $manager) | |
{ | |
$this->createMany(Article::class, 10, function(Article $article, $count) { | |
$article->setTitle('Why Asteroids Taste Like Bacon') | |
->setSlug('why-asteroids-taste-like-bacon-'.$count) | |
->setContent(<<<EOF | |
Spicy **jalapeno bacon** ipsum dolor amet veniam shank in dolore. Ham hock nisi landjaeger cow, | |
lorem proident [beef ribs](https://baconipsum.com/) aute enim veniam ut cillum pork chuck picanha. Dolore reprehenderit | |
labore minim pork belly spare ribs cupim short loin in. Elit exercitation eiusmod dolore cow | |
**turkey** shank eu pork belly meatball non cupim. | |
Laboris beef ribs fatback fugiat eiusmod jowl kielbasa alcatra dolore velit ea ball tip. Pariatur | |
laboris sunt venison, et laborum dolore minim non meatball. Shankle eu flank aliqua shoulder, | |
capicola biltong frankfurter boudin cupim officia. Exercitation fugiat consectetur ham. Adipisicing | |
picanha shank et filet mignon pork belly ut ullamco. Irure velit turducken ground round doner incididunt | |
occaecat lorem meatball prosciutto quis strip steak. | |
Meatball adipisicing ribeye bacon strip steak eu. Consectetur ham hock pork hamburger enim strip steak | |
mollit quis officia meatloaf tri-tip swine. Cow ut reprehenderit, buffalo incididunt in filet mignon | |
strip steak pork belly aliquip capicola officia. Labore deserunt esse chicken lorem shoulder tail consectetur | |
cow est ribeye adipisicing. Pig hamburger pork belly enim. Do porchetta minim capicola irure pancetta chuck | |
fugiat. | |
EOF | |
); | |
// publish most articles | |
if (rand(1, 10) > 2) { | |
$article->setPublishedAt(new \DateTime(sprintf('-%d days', rand(1, 100)))); | |
} | |
$article->setAuthor('Mike Ferengi') | |
->setHeartCount(rand(5, 100)) | |
->setImageFilename('asteroid.jpeg') | |
; | |
}); | |
... lines 45 - 46 | |
} | |
} |
At the bottom, the persist isn't hurting anything, but it's not needed anymore.
Finish the end with a closing parenthesis and a semicolon:
... lines 1 - 7 | |
class ArticleFixtures extends BaseFixture | |
{ | |
public function loadData(ObjectManager $manager) | |
{ | |
$this->createMany(Article::class, 10, function(Article $article, $count) { | |
$article->setTitle('Why Asteroids Taste Like Bacon') | |
->setSlug('why-asteroids-taste-like-bacon-'.$count) | |
->setContent(<<<EOF | |
Spicy **jalapeno bacon** ipsum dolor amet veniam shank in dolore. Ham hock nisi landjaeger cow, | |
lorem proident [beef ribs](https://baconipsum.com/) aute enim veniam ut cillum pork chuck picanha. Dolore reprehenderit | |
labore minim pork belly spare ribs cupim short loin in. Elit exercitation eiusmod dolore cow | |
**turkey** shank eu pork belly meatball non cupim. | |
Laboris beef ribs fatback fugiat eiusmod jowl kielbasa alcatra dolore velit ea ball tip. Pariatur | |
laboris sunt venison, et laborum dolore minim non meatball. Shankle eu flank aliqua shoulder, | |
capicola biltong frankfurter boudin cupim officia. Exercitation fugiat consectetur ham. Adipisicing | |
picanha shank et filet mignon pork belly ut ullamco. Irure velit turducken ground round doner incididunt | |
occaecat lorem meatball prosciutto quis strip steak. | |
Meatball adipisicing ribeye bacon strip steak eu. Consectetur ham hock pork hamburger enim strip steak | |
mollit quis officia meatloaf tri-tip swine. Cow ut reprehenderit, buffalo incididunt in filet mignon | |
strip steak pork belly aliquip capicola officia. Labore deserunt esse chicken lorem shoulder tail consectetur | |
cow est ribeye adipisicing. Pig hamburger pork belly enim. Do porchetta minim capicola irure pancetta chuck | |
fugiat. | |
EOF | |
); | |
// publish most articles | |
if (rand(1, 10) > 2) { | |
$article->setPublishedAt(new \DateTime(sprintf('-%d days', rand(1, 100)))); | |
} | |
$article->setAuthor('Mike Ferengi') | |
->setHeartCount(rand(5, 100)) | |
->setImageFilename('asteroid.jpeg') | |
; | |
}); | |
$manager->flush(); | |
} | |
} |
So, it's a little bit fancier, and it'll save that important reference for us. Let's try it! Reload the fixtures again:
php bin/console doctrine:fixtures:load
No errors! Refresh the homepage: ah, our same, boring list of 10 identical articles. In the next chapter, let's use an awesome library called Faker to give each article rich, unique, realistic data.
Hey jpfortuno
As far as I know, Doctrine refactored its namespace in a recent version. The old namespace is Doctrine\Common\Persistence\ObjectManager
and now you should use the other one. I believe they didn't change any behavior
Cheers!
Hello,
I followed this Tutorial step-by-step and everything worked till I was trying to install the fixtures-bundle
I tried following commands:
`
composer require orm-fixtures --dev
composer require --dev orm-fixtures
composer require --dev doctrine/doctrine-fixtures-bundle
`
all of these commands ended up with the same result:
`
Using version ^3.1 for doctrine/doctrine-fixtures-bundle
./composer.json has been updated
Loading composer repositories with package information
Updating dependencies (including require-dev)
Your requirements could not be resolved to an installable set of packages.
Problem 1
- Installation request for doctrine/doctrine-fixtures-bundle ^3.1 -> satisfiable by doctrine/doctrine-fixtures-bundle[3.1.0].
- Conclusion: don't install symfony/framework-bundle v4.2.3
- Conclusion: don't install symfony/framework-bundle v4.2.2
- Conclusion: don't install symfony/framework-bundle v4.2.1
- Conclusion: don't install symfony/framework-bundle v4.2.0
- Conclusion: don't install symfony/framework-bundle v4.1.11
- Conclusion: don't install symfony/framework-bundle v4.1.10
- Conclusion: don't install symfony/framework-bundle v4.1.9
- Conclusion: don't install symfony/framework-bundle v4.1.8
- Conclusion: don't install symfony/framework-bundle v4.1.7
- Conclusion: don't install symfony/framework-bundle v4.1.6
- Conclusion: don't install symfony/framework-bundle v4.1.5
- Conclusion: don't install symfony/framework-bundle v4.1.4
- Installation request for symfony/twig-bridge (locked at v4.0.4) -> satisfiable by symfony/twig-bridge[v4.0.4].
- Conclusion: don't install symfony/framework-bundle v4.1.3
- Conclusion: don't install symfony/framework-bundle v4.1.2
- Can only install one of: symfony/framework-bundle[v4.1.0, v4.0.14].
- Can only install one of: symfony/framework-bundle[v4.1.0, v4.0.14].
- Can only install one of: symfony/framework-bundle[v4.1.0, v4.0.14].
- doctrine/doctrine-fixtures-bundle 3.1.0 requires symfony/framework-bundle ^3.4|^4.1 -> satisfiable by symfony/framework-bundle[v4.1.0, v4.1.1, v4.1.10, v4.1.11, v4.1.2, v4.1.3, v4.1.4, v4.1.5, v4.1.6, v4.1.7, v4.1.8, v4.1.9, v4.2.0, v4.2.1, v4.2.2, v4.2.3].
- Conclusion: don't install symfony/framework-bundle v4.1.1
- Installation request for symfony/framework-bundle (locked at v4.0.14, required as ^4.0) -> satisfiable by symfony/framework-bundle[v4.0.14].
Installation failed, reverting ./composer.json to its original content.
`
any idea why this isn't working for me? till this point I didn't have any troubles with composer require
with best regards
Sam
Hello again,
installing doctrine-fixture-bundle v2.4 with the cmd:<br />composer require --dev doctrine/doctrine-fixtures-bundle 2.4<br />
worked for me. But I am still interested in how I can get the more recent version of orm-fixtures-bundle <3
welp, i cannot access the load-command in console with this solutionbin/console doctrine:fixtures:load
results inThere are no commands defined in the "doctrine:fixtures" namespace.
running:bin/console debug:config DoctrineFixturesBundle
displays me following:Bundle "DoctrineFixturesBundle" does not have a container extension.
do I have to add something within the configuration?
Btw feel free to delete this comment/conversion if you guys think its to much or just stupid ;)
with best regards
Sam
Hi AndTheGodsMadeLove
Sorry for this issue!
doctrine-fixtures-bundle
has been updated since course came out. We used version "3.0.2
" in this tutorial, try to install it, and report us back if it solved your issue.
Cheers!
Hello Vladimir Sadicov,
works like a charm! I cannot thank you enough for you fast and competent response! Also I'm sorry for spamming your comment-section.
<3 Sam
Bro I really didn't get the whole callable thing...the $factory($entity, $i) is doing what exactly? Please give me a direction to understand this. Yours trully - Guilherme
Hey Gssj
Yeah that look tricky =) but also it's simple. Look $factory
is a callable and in our case it will be anonymous function which will be declared in our fixtures classes for example here https://symfonycasts.com/screencast/symfony4-doctrine/fixtures#codeblock-0372f09dc8
so this code will execute function with our $entity
and $i
arguments
Cheers!
HI all!
I'm currently facing an issue when trying to load via composer the Doctrine fixtures bundle.I've seen different topics on Github and Stackoverflow but I can't resolve my problem . All the solutions below don't work for me either. I tried to see solutions with Symfony 5 tutorial but fixtures are already loaded int his project
Here is my composer.json file:
"require": {
"php": "^7.1.3",
"ext-ctype": "*",
"ext-iconv": "*",
"composer/package-versions-deprecated": "^1.11",
"doctrine/doctrine-bundle": "^2.1",
"doctrine/doctrine-migrations-bundle": "^3.0",
"doctrine/orm": "^2.7",
"knplabs/knp-markdown-bundle": "^1.8",
"knplabs/knp-time-bundle": "^1.13",
"nexylan/slack-bundle": "2.2.0",
"php-http/guzzle6-adapter": "1.1.1",
"sensio/framework-extra-bundle": "^5.5",
"symfony/asset": "4.4.*",
"symfony/console": "4.4.*",
"symfony/debug-bundle": "4.4.*",
"symfony/dotenv": "4.4.*",
"symfony/flex": "^1.3.1",
"symfony/framework-bundle": "4.4.*",
"symfony/maker-bundle": "^1.21",
"symfony/monolog-bundle": "^3.0",
"symfony/stopwatch": "4.4.*",
"symfony/twig-bundle": "4.4.*",
"symfony/var-dumper": "4.4.*",
"symfony/web-profiler-bundle": "4.4.*",
"symfony/web-server-bundle": "4.4.*",
"symfony/yaml": "4.4.*",
"twig/extra-bundle": "^2.12|^3.0",
"twig/twig": "^2.12|^3.0"
},
"require-dev": {
"sensiolabs/security-checker": "^6.0",
"symfony/stopwatch": "^4.4",
"symfony/twig-bundle": "^4.4",
"symfony/web-profiler-bundle": "^4.4" etc...
And here is the result:
`Your requirements could not be resolved to an installable set of packages.
Problem 1
- Conclusion: don't install doctrine/doctrine-fixtures-bundle 3.3.1
- Conclusion: remove doctrine/cache 1.10.2
- Conclusion: don't install doctrine/cache 1.10.2
- doctrine/common 2.2.1 conflicts with doctrine/cache[1.10.2].
- doctrine/common 2.2.2 conflicts with doctrine/cache[1.10.2].
- doctrine/common 2.2.3 conflicts with doctrine/cache[1.10.2].
- doctrine/common 2.3.0 conflicts with doctrine/cache[1.10.2].
- Conclusion: don't install doctrine/common 3.0.2|install doctrine/common 2.2.1|install doctrine/common 2.2.2|install doctrine/common 2.2.3|install doctrine/common 2.3.0
- Conclusion: don't install doctrine/doctrine-fixtures-bundle 3.3.1|remove doctrine/common 3.0.2|install doctrine/common 2.2.1|install doctrine/common 2.2.2|install doctrine/common 2.2.3|install doctrine/common 2.3.0
- Conclusion: don't install doctrine/doctrine-fixtures-bundle 3.3.1|don't install doctrine/common 3.0.2|install doctrine/common 2.2.1|install doctrine/common 2.2.2|install doctrine/common 2.2.3|install doctrine/common 2.3.0
- Installation request for doctrine/cache (locked at 1.10.2) -> satisfiable by doctrine/cache[1.10.2].
- Conclusion: don't install doctrine/doctrine-fixtures-bundle 3.3.1|remove doctrine/common 3.0.2|install doctrine/common 2.2.1|install doctrine/common 2.2.2|install doctrine/common 2.2.3|install doctrine/common 2.3.0
- Conclusion: don't install doctrine/doctrine-fixtures-bundle 3.3.1|don't install doctrine/common 3.0.2|install doctrine/common 2.2.1|install doctrine/common 2.2.2|install doctrine/common 2.2.3|install doctrine/common 2.3.0
- Installation request for doctrine/doctrine-fixtures-bundle ^3.3 -> satisfiable by doctrine/doctrine-fixtures-bundle[3.3.0, 3.3.1].
- Conclusion: remove doctrine/common 3.0.2|install doctrine/common 2.2.1|install doctrine/common 2.2.2|install doctrine/common 2.2.3|install doctrine/common 2.3.0
- doctrine/doctrine-fixtures-bundle 3.3.0 requires doctrine/data-fixtures ^1.3 -> satisfiable by doctrine/data-fixtures[1.3.3, 1.4.0, 1.4.1, 1.4.2, 1.4.3, v1.3.0, v1.3.1, v1.3.2].
- doctrine/data-fixtures 1.3.3 requires doctrine/common ~2.2 -> satisfiable by doctrine/common[2.12.0, 2.13.0, 2.13.1, 2.13.2, 2.13.3, 2.2.0, 2.2.1, 2.2.2, 2.2.3, 2.3.0, v2.10.0, v2.11.0, v2.4.0, v2.4.1, v2.4.2, v2.4.3, v2.5.0, v2.5.1, v2.5.2, v2.5.3, v2.6.0, v2.6.1, v2.6.2, v2.7.0, v2.7.1, v2.7.2, v2.7.3, v2.8.0, v2.8.1,
v2.9.0].
- doctrine/data-fixtures 1.4.0 requires doctrine/common ^2.11 -> satisfiable by doctrine/common[2.12.0, 2.13.0, 2.13.1, 2.13.2, 2.13.3, v2.11.0].
- doctrine/data-fixtures 1.4.1 requires doctrine/common ^2.11 -> satisfiable by doctrine/common[2.12.0, 2.13.0, 2.13.1, 2.13.2, 2.13.3, v2.11.0].
- doctrine/data-fixtures 1.4.2 requires doctrine/common ^2.11 -> satisfiable by doctrine/common[2.12.0, 2.13.0, 2.13.1, 2.13.2, 2.13.3, v2.11.0].
- doctrine/data-fixtures 1.4.3 requires doctrine/common ^2.11 -> satisfiable by doctrine/common[2.12.0, 2.13.0, 2.13.1, 2.13.2, 2.13.3, v2.11.0].
- doctrine/data-fixtures v1.3.0 requires doctrine/common ~2.2 -> satisfiable by doctrine/common[2.12.0, 2.13.0, 2.13.1, 2.13.2, 2.13.3, 2.2.0, 2.2.1, 2.2.2, 2.2.3, 2.3.0, v2.10.0, v2.11.0, v2.4.0, v2.4.1, v2.4.2, v2.4.3, v2.5.0, v2.5.1, v2.5.2, v2.5.3, v2.6.0, v2.6.1, v2.6.2, v2.7.0, v2.7.1, v2.7.2, v2.7.3, v2.8.0, v2.8.1, v2.9.0].
- doctrine/data-fixtures v1.3.1 requires doctrine/common ~2.2 -> satisfiable by doctrine/common[2.12.0, 2.13.0, 2.13.1, 2.13.2, 2.13.3, 2.2.0, 2.2.1, 2.2.2, 2.2.3, 2.3.0, v2.10.0, v2.11.0, v2.4.0, v2.4.1, v2.4.2, v2.4.3, v2.5.0, v2.5.1, v2.5.2, v2.5.3, v2.6.0, v2.6.1, v2.6.2, v2.7.0, v2.7.1, v2.7.2, v2.7.3, v2.8.0, v2.8.1, v2.9.0].
- doctrine/data-fixtures v1.3.2 requires doctrine/common ~2.2 -> satisfiable by doctrine/common[2.12.0, 2.13.0, 2.13.1, 2.13.2, 2.13.3, 2.2.0, 2.2.1, 2.2.2, 2.2.3, 2.3.0, v2.10.0, v2.11.0, v2.4.0, v2.4.1, v2.4.2, v2.4.3, v2.5.0, v2.5.1, v2.5.2, v2.5.3, v2.6.0, v2.6.1, v2.6.2, v2.7.0, v2.7.1, v2.7.2, v2.7.3, v2.8.0, v2.8.1, v2.9.0].
- Can only install one of: doctrine/common[2.12.0, 3.0.2].
- Can only install one of: doctrine/common[2.13.0, 3.0.2].
- Can only install one of: doctrine/common[2.13.1, 3.0.2].
- Can only install one of: doctrine/common[2.13.2, 3.0.2].
- Can only install one of: doctrine/common[2.13.3, 3.0.2].
- Can only install one of: doctrine/common[v2.11.0, 3.0.2].
- Can only install one of: doctrine/common[2.2.0, 3.0.2].
- Can only install one of: doctrine/common[v2.10.0, 3.0.2].
- Can only install one of: doctrine/common[v2.4.0, 3.0.2].
- Can only install one of: doctrine/common[v2.4.1, 3.0.2].
- Can only install one of: doctrine/common[v2.4.2, 3.0.2].
- Can only install one of: doctrine/common[v2.4.3, 3.0.2].
- Can only install one of: doctrine/common[v2.5.0, 3.0.2].
- Can only install one of: doctrine/common[v2.5.1, 3.0.2].
- Can only install one of: doctrine/common[v2.5.2, 3.0.2].
- Can only install one of: doctrine/common[v2.5.3, 3.0.2].
- Can only install one of: doctrine/common[v2.6.0, 3.0.2].
- Can only install one of: doctrine/common[v2.6.1, 3.0.2].
- Can only install one of: doctrine/common[v2.6.2, 3.0.2].
- Can only install one of: doctrine/common[v2.7.0, 3.0.2].
- Can only install one of: doctrine/common[v2.7.1, 3.0.2].
- Can only install one of: doctrine/common[v2.7.2, 3.0.2].
- Can only install one of: doctrine/common[v2.7.3, 3.0.2].
- Can only install one of: doctrine/common[v2.8.0, 3.0.2].
- Can only install one of: doctrine/common[v2.8.1, 3.0.2].
- Can only install one of: doctrine/common[v2.9.0, 3.0.2].
- Installation request for doctrine/common (locked at 3.0.2) -> satisfiable by doctrine/common[3.0.2].`
Can someone help me? thx!
Hey Valgritim
Try updating Doctrine dependencies first. Run
composer upgrade "doctrine/*" --with-dependencies```
Let me know if it worked. Cheers!
Yep, I do! I found what's happening. You have to require the fixtures library like this composer require orm-fixtures:3.0.2 --dev
because this tutorial was built on Symfony4.0 and it's hard to make it work with all new libraries versions
Before you do that you'll have to update the fixture class that comes with the course code. Inside src/DataFxitures/AppFixtures.php
change line 6Doctrine\Persistence\ObjectManager
to this use Doctrine\Common\Persistence\ObjectManager;
Short story of this change. Doctrine renamed some namespaces of his project.
Hi Diego!
Thank you for your help!
Here is the result of composer require orm-fixtures:3.0.2 --dev :
./composer.json has been updated
Loading composer repositories with package information
Updating dependencies (including require-dev)
Restricting packages listed in "symfony/symfony" to "4.4.*"
Your requirements could not be resolved to an installable set of packages.
Problem 1
- Installation request for doctrine/doctrine-fixtures-bundle 3.0.2 -> satisfiable by doctrine/doctrine-fixtures-bundle[3.0.2].
- doctrine/doctrine-fixtures-bundle 3.0.2 requires doctrine/doctrine-bundle ~1.0 -> satisfiable by doctrine/doctrine-bundle[1.1.x-dev, 1.10.0, 1.10.1, 1.10.2, 1.10.3, 1.10.x-dev, 1.11.0, 1.11.1, 1.11.2, 1.11.x-dev, 1.12.0, 1.12.0-Beta1, 1.12.1, 1.12.10, 1.12.2, 1.12.3, 1.12.4, 1.12.5, 1.12.6, 1.12.7, 1.12.8, 1.12.9, 1.12.x-dev, 1.2.x-dev, 1.3.x-dev, 1.4.x-dev, 1.5.x-dev, 1.6.0, 1.6.1, 1.6.10, 1.6.11, 1.6.12, 1.6.13, 1.6.2, 1.6.3, 1.6.4, 1.6.5, 1.6.6, 1.6.7, 1.6.8, 1.6.9, 1.6.x-dev, 1.7.0, 1.7.1, 1.7.2, 1.7.x-dev, 1.8.0, 1.8.1, 1.8.x-dev, 1.9.0, 1.9.1, 1.9.x-dev, v1.0.0, v1.0.0-RC1, v1.0.0-beta1, v1.1.0, v1.2.0, v1.2.0-beta1, v1.3.0, v1.3.0-beta1, v1.3.0-beta2, v1.4.0, v1.5.0, v1.5.1, v1.5.2] but these conflict with your requirements or minimum-stability.
So what to do now..? :(
Ohh you're on Symfony 4.4 and you're using DoctrineBundle 2.x - You didn't download the course code, did you? :)
The problem is the doctrine/cache
library, you can try removing it or, probably a better solution would be to downgrade doctrine/doctrine-bundle
to version 1 (you're on version 2)
hi MolloKhan I removed doctrine/cache library and it worked! yeahhhh!! I hope I won't have any problem after that! Thanks for your help!
Cheers,
Val
I need to clarify something. The file src/DataFxitures/AppFixtures.php
doesn't come with the tutorial, it's created by the recipe of the DoctrineFixturesBundle
Can fixtures be used to load real data to the database? Say we have a table with a long fixed list of statuses that needs to be pre-filled on each deployment, is there a 'right way' to do it? Or should it be simply an SQL insert script that will be run on every new installation?
Hey jpfortuno
That's a good question :)
In theory, I think it's possible but I wouldn't recommend it because fixtures are intended to only be load in a dev or test environment. What I recommend is to export / import your database, or as you said write your own SQL queries and run them on deploy.
Cheers!
Hi,
I notice a minor issue when following along with Symfony 5. `make:fixtures` generates ArticleFixtures with `use Doctrine\Common\Persistence\ObjectManager` - note `\Common\` in the namespace path. ArticleFixtures, as generated, extends Doctrine\Bundle\FixturesBundle\Fixture. So far so good.
Our generated `load()` method implements, according to PhpStorm (it's through a chain of interfaces extending interfaces!), the method from interface Doctrine\Common\DataFixtures\FixtureInterface. However, this interface has `use Doctrine\Persistence\ObjectManager`. Note we do NOT have `\Common\` in the namespace path.
Meanwhile, Doctrine\Common\Persistence\ObjectManager has a `class_alias()` built in. At the same time Doctrine\Persistence\ObjectManager is an interface, and below the interface declaration is `interface_exists(\Doctrine\Common\Persistence\ObjectManager::class);`.
So... it looks like everything is wired-together as intended, but PhpStorm is confused by the parent class having an ObjectManager type hint that's different from the generated child ArticleFixtures class. I don't think there's anything here to be reported as a Doctrine issue, but wanted to let SymfonyCasts be aware of this minor item when developing the Symfony 5 version of this tutorial.
Hey Edward B.
That was an excellent research! The key thing here is Symfony5 uses DoctrineBundle 2, not version one as Symfony4 does (That's the Symfony version we used for this tutorial). DoctrineBundle2 comes with many changes to its structure and what you just said is one of them, they split the Doctrine\Common
package into different ones. You can learn more about those changes in this video: https://symfonycasts.com/screencast/symfony5-upgrade/doctrine-bundle-2.0 (and the subsequent one)
Cheers!
Hello ! I did exactly what was said in this good tutorial but each time i try to load fixtures I got :
Call to a member function persist() on null
in the terminal. I tried to read the tuto again many times but i cannot see this error. And i found nothing on Google about that issue.
Do you have an idea of what's going on ?
thanks
I finally solved my problem. I droped $this->manager = $manager from the load method in BaseFixtures class. So there was no manager when I loaded the fixture. Then I worte it again and now everything works just fine !
Thanks ;-)
lol.! sometimes I feel very stupid when I have those little problems ;-) ;-) makes me think that I have to focus more on my code ;-) ;-) Thanks for sharing !
Hi.
Can I seeding real data by fixtures, or I need another tool?
I try to rewrite my project and transfer data from mySql to PostgreSql, with resturcture schema of data base.
What is better way to do this?
Hey Damir,
Well, technically you can, but keep in mind that running fixtures will purge the entire DB and all the data you have in it. Well, you can use "--append" option, i.e. run "php bin/console doctrine:fixtures:load --append" that won't remove the existent data but just add it. Though, it sounds weird, because of most of the time you would like to do it only once and forget about on production, so it's almost pointless to write fixtures and only run it once. If you want to "migrate" some data - you better use migrations instead. So, fixtures is something special for test/dev modes only, when you want to be able load soma data quickly and more than once.
About migration, it can be doctrine migration bundle where you can create a migration, e.g. with "bin/console make:migration" command if you have MakerBundle installed. But in more complex examples, like in your case probably, I'd recommend you to create a "migration command" - it's just a regular Symfony command that you write to migrate and then you can completely delete it forever after it did its job.
I hope this helps!
Cheers!
Victor, thanks for answer.
Do you mean to write sql requests with "INSERT" for every tabels in migration file to add data, and then run "bin/console doctrine:migrations:migrate"?
Hey Damir,
Yes, exactly. It's fine for short operations and is used exactly for these purposes. If you have tons of data or you need to do more complex things - then consider creating a custom migration command instead of just simple migration.
Cheers!
Victor, thank you one more time!
It's very usefull for me. I migrated data to postgresql by copying and editing requests from sql file.
Hello!
After follow this tutorial, I've an error and I don't understrand why...
`In AbstractMySQLDriver.php line 103:
An exception occurred while executing 'INSERT INTO article (title, slug, content,
published_at, author, heart_count, image_filename) VALUES (?, ?, ?, ?, ?, ?, ?)' w
ith params [null, null, null, null, null, 0, null]:
SQLSTATE[23000]: Integrity constraint violation: 1048 Column 'title' cannot be nul
l`
It told me the same for PDOStatement.php file
SQLSTATE[23000]: Integrity constraint violation: 1048 Column 'title' cannot be nul<br /> l<br />
Someone to help me please ?
My bad, I've found the problem! But now It told me
SQLSTATE[23000]: Integrity constraint violation: 1048 Column 'published_at' cannot
be null
Hey Galnash!
Make sure you have the nullable=true
option on your publishedAt property:
/**
* @ORM\Column(type="datetime", nullable=true)
*/
private $publishedAt;
You'll need to generate a new migration and execute it after this change, as this needs to change how the column is configured in the database.
Hope this helps!
Cheers!
Hello Weaverryan!
Thank you for your answer, everything works! I didn't think about to pass it to nullable=true.
Thank you!
Actually I can't get the Fixtures working, I get an error about the abstract method:
Error: Class App\DataFixtures\BaseFixture contains 1 abstract method and must therefore be declared abstract or implement the remaining methods (App\DataFixtures\BaseFixture::loadData)
Hey AymDev
If your fixtures are extending from App\DataFixtures\BaseFixture
then you must implement loadData()
method because that method is abstract.
Cheers!
Hello, why are you using Doctrine Fixtures not Hautelook Fixtures (https://github.com/hauteloo...
In Symfony 3 tutorial you used it and it was g8. Why did you change it? Sth happened?
Hey @Dominik!
Great question! The latest version of AliceBundle became overly-complicated in my opinion - the bundle requires several other libraries and extending it became more difficult. The great thing about Alice was how simple and fun it is! By adding these extra complexities, I no longer felt that it was worth using. However, there is definitely nothing wrong with it.
Instead, as you'll see in this tutorial, we recreate a few of Alice's best features (like faker, the ability to create many objects at once, and the ability to reference other objects randomly for relationships) in normal, PHP code. I hope this is the best of both worlds, and we may even be able to add these features to DoctrineFixturesBundle at some point :).
Cheers!
Hi there!
This is a non technical question. I will understand if you delete it if you consider it off-topic.
I don't understand why we will need to create a fixture class. So, what's the goal of the creation of this type of class?
Cheers.
Hey Abelardo L.
Fixtures are useful for seeding your local website with "dummy" information and be able to see how it would look like in production.
Cheers!
Fixtures seem great for test data. However, what about production-necessary default data? For example, our app has a table of workflow actions. When we deploy a new database, it should have a set of default workflow actions. Currently, I use a home-grown migration like system that we call self-healing. But, if there is a way to do it in symfony land, I'd be very interested.
Hey Amy anuszewski
Nice question :)
There is a way to run your fixtures for a production environment, but I wouldn't recommend it, it could be fatal if you use it wrongly, so, another approach would be to create a Symfony command that will load all the required information into the DB
Here you can read how to implement your own commands: https://symfony.com/doc/2.6...
Cheers!
If we have tables, with default data, what is the best way to deploy them to the production?
Is this "correct" way:
1. Create, a command which will insert default data
2. Any time when we cloning code we need to run the command to get default data
And if we will go this way, running "fixtures:load" will truncate tables with default data.
// composer.json
{
"require": {
"php": "^7.1.3",
"ext-iconv": "*",
"composer/package-versions-deprecated": "^1.11", // 1.11.99
"knplabs/knp-markdown-bundle": "^1.7", // 1.7.0
"knplabs/knp-time-bundle": "^1.8", // 1.8.0
"nexylan/slack-bundle": "^2.0,<2.2.0", // v2.0.0
"php-http/guzzle6-adapter": "^1.1", // v1.1.1
"sensio/framework-extra-bundle": "^5.1", // v5.1.4
"stof/doctrine-extensions-bundle": "^1.3", // v1.3.0
"symfony/asset": "^4.0", // v4.0.4
"symfony/console": "^4.0", // v4.0.14
"symfony/flex": "^1.0", // v1.17.6
"symfony/framework-bundle": "^4.0", // v4.0.14
"symfony/lts": "^4@dev", // dev-master
"symfony/orm-pack": "^1.0", // v1.0.6
"symfony/twig-bundle": "^4.0", // v4.0.4
"symfony/web-server-bundle": "^4.0", // v4.0.4
"symfony/yaml": "^4.0" // v4.0.14
},
"require-dev": {
"doctrine/doctrine-fixtures-bundle": "^3.0", // 3.0.2
"easycorp/easy-log-handler": "^1.0.2", // v1.0.4
"fzaninotto/faker": "^1.7", // v1.7.1
"symfony/debug-bundle": "^3.3|^4.0", // v4.0.4
"symfony/dotenv": "^4.0", // v4.0.14
"symfony/maker-bundle": "^1.0", // v1.4.0
"symfony/monolog-bundle": "^3.0", // v3.1.2
"symfony/phpunit-bridge": "^3.3|^4.0", // v4.0.4
"symfony/profiler-pack": "^1.0", // v1.0.3
"symfony/var-dumper": "^3.3|^4.0" // v4.0.4
}
}
what's the difference between
use Doctrine\Persistence\ObjectManager; and use Doctrine\Common\Persistence\ObjectManager;