// composer.json
{
"require": {
"php": "^7.1.3",
"ext-iconv": "*",
"composer/package-versions-deprecated": "^1.11", // 1.11.99
"doctrine/doctrine-bundle": "^1.6.10", // 1.10.2
"doctrine/doctrine-migrations-bundle": "^1.3|^2.0", // v2.0.0
"doctrine/orm": "^2.5.11", // v2.7.2
"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.21.6
"symfony/framework-bundle": "^4.0", // v4.0.14
"symfony/lts": "^4@dev", // dev-master
"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/stopwatch": "^3.3|^4.0", // v4.0.4
"symfony/var-dumper": "^3.3|^4.0", // v4.0.4
"symfony/web-profiler-bundle": "^3.3|^4.0" // v4.0.4
}
}
48 Comments
what's the difference between
use Doctrine\Persistence\ObjectManager; and use Doctrine\Common\Persistence\ObjectManager;
Hey jpfortuno
As far as I know, Doctrine refactored its namespace in a recent version. The old namespace is
Doctrine\Common\Persistence\ObjectManagerand now you should use the other one. I believe they didn't change any behaviorCheers!
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 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
I experienced the same problem. `composer update` fixed it.
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 solution
bin/console doctrine:fixtures:loadresults in
There are no commands defined in the "doctrine:fixtures" namespace.running:
bin/console debug:config DoctrineFixturesBundledisplays 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-bundlehas 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
$factoryis 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-0372f09dc8so this code will execute function with our
$entityand$iargumentsCheers!
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": {
"symfony/stopwatch": "4.4.*",
And here is the result:
`Your requirements could not be resolved to an installable set of packages.
Problem 1
v2.9.0].
Can someone help me? thx!
Hey Valgritim
Try updating Doctrine dependencies first. Run
Hey
Thanks for your help!
Same ugly error once again! Do you have any other solution?
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 --devbecause 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.phpchange line 6Doctrine\Persistence\ObjectManagerto thisuse 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/cachelibrary, you can try removing it or, probably a better solution would be to downgradedoctrine/doctrine-bundleto 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.phpdoesn't come with the tutorial, it's created by the recipe of theDoctrineFixturesBundleCan 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\Commonpackage 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 ;-)
Hey i had the same problem, I fixed it by adding the line you where missing back in.. lol.
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 !
Hey Stephane K. !
That's really great, you solved it!
Stay on tune! Cheers!
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.
Hey Damir,
Great! I'm happy it helped you ;)
Cheers!
Thank you again!
I understand.
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
Hey Galnash!
Make sure you have the
nullable=trueoption on your publishedAt property: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\BaseFixturethen you must implementloadData()method because that method is abstract.Cheers!
I forgot to make the
BaseFixtureclass abstract... Thanks for your quick answer !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.
"Houston: no signs of life"
Start the conversation!