search

doctrine / data-fixtures

Doctrine2 ORM Data Fixtures Extensions
http://www.doctrine-project.org
MIT License
2.77k stars 224 forks source link

Allowing getDependencies() to be empty #279

Closed weaverryan closed 6 years ago

weaverryan commented 6 years ago

Hi guys!

I'm re-proposing this idea, as it continues to be a little "usability" thorn. But now, we have slightly different reasons for how I would like to expose this to users. Basically:

1) I think defining getDependencies() is the best way or ordering your fixtures 2) In the Symfony world, we will likely add a make:fixtures command to generate the class for you 3) I would love to generate a skeleton that already has the getDependencies() method defined. It would default to empty. If the user never cares, they will just ignore it.

By allowing getDependencies() to be empty, we can "nudge" the user towards this "best way" of defining fixture ordering by generating this method for them. This makes the feature "discoverable".

Thanks!

joshlopes commented 6 years ago

It would rather bloat your fixtures with an unwanted interface and empty method. Can you give a scenario where in symfony world make:fixtures would generate a class that is dependent on something ? I think you can't automate this without being tricky or force the user to follow a specific use-case.

alcaeus commented 6 years ago

This has been discussed at length in #252. From this libraries' perspective, a class should only implement the DependentFixtureInterface if it actually has dependencies. The previous use-case was the bundle providing a base class that implemented the DependentFixtureInterface, with a recommandation to use that base class. With the latest version of the bundle, this is no longer the case, with people having to explicitly mark their fixtures as dependent and listing any dependencies of the fixture.

Going through the individual points:

  1. I think defining getDependencies() is the best way or ordering your fixtures

There is OrderedFixtureInterface which is used for ordering fixtures. DependentFixtureInterface is there to specify dependencies that your fixture can't work without. These are two different concepts and one shouldn't be used to replace the other. If your fixture requires a different fixture to run successfully, implement the DependentFixtureInterface and list the dependencies.

  1. In the Symfony world, we will likely add a make:fixtures command to generate the class for you

While I believe the IDE can generate empty class skeletons as well, this is perfectly fine and doesn't require a change here.

  1. I would love to generate a skeleton that already has the getDependencies() method defined. It would default to empty. If the user never cares, they will just ignore it.

This is the wrong approach IMO. Things should be kept simple for the user. Just because there's an empty getDependencies method will not make the user understand what it is - it will most likely be empty by default and only get filled in a few cases. I believe the better option is to solve this using documentation (see the bundle docs for example, where DependentFixtureInterface is explained); if need be this can be added as a comment to the class template in the maker bundle, but this is nothing that should be solved in this library.

weaverryan commented 6 years ago

Hi guys!

Well, I disagree of course, and am a bit frustrated tbh. But, I'll live to fight a different battle :). I hope we can continue to work together then :)

Cheers!