Closed yann-eugone closed 4 years ago
This was discussed a couple of years ago. The simple answer is "it has always been that way", which was recently justified with "you shouldn't implement the interface if you don't have dependencies". The topic of dynamic dependencies has been dismissed, in that you should rather split the fixture classes and use common logic (e.g. by extending base classes) to avoid such dynamic dependencies in favour of explicit ones.
I'm a bit worried of the "it has always been that way" response, but you are free to keep it like this.
For the archive, and those who read that in some time, you can just add a DummyFixture as dependency of every other, this is an ugly but perfect workaround.
I was working on a fixture base class that determine dependencies "automatically" using entity metadata introspection. I encountered an exception with a fixture class, implementing
DependentFixtureInterface
and methodgetDependencies
returning an empty array.This is, regarding the code, a normal behaviour : https://github.com/doctrine/data-fixtures/blob/master/lib/Doctrine/Common/DataFixtures/Loader.php#L301-L307
But I was wondering : should that class be considered as a regular fixture class during the sorting process ? This is pretty much a fixture without any dependency in the end...
If you are interested in such change, I can offer a PR.