[LoadDataFixturesDoctrineCommand] doctrine:fixtures:load --env=test

[liuggio]

Hi,

Usually when we develop we have more than one set of fixtures,
for example, the fixtures are many more on stage than on test
So we created two folder foreach bundle

DataFixtures / test / ORM / ...
DataFixtures / ORM / ... // stage

It would be nice if you could load a set of fixtures
depending from wich environment you select, for example for the 'dev' env.
would be loaded the fixtures in bundleName / DataFixtures / dev / ORM / ...

The solution is easy just add a parameter and add a row on the row number 90.

I could do it, what do you think?

[stof]

you can already achieve such thing with the --feature-path option giving the path to the directory to load (you can use the option several times)

[liuggio]

Hi thanks for the reply
is not properly the same,
with --feature you have to know all the bundles path.
The solution could be put the prefix into the arguments of the command
or saving the path into the config eg. parameter.ini for the fixtures path
now is hardcoded into the php ('/DataFixtures/ORM')

So we will have foreach envorinment the correct fixtures

[ptitcub]

indeed, --env option could be very usefull to test on each environment...

thx

[liuggio]

@ptitcub that option already exist, but there's no way to use different fixtures for differents env

[roberteikermann]

Hi, i think it's a very common usecase to have different fixtures in the environments like test,prod,dev. I understand that one could achive such behavior with the fixture parameter, but I think there should be a more convenient way to do that. Additionally I would like to recommend to have something like 'inheritance'. That would allow a set of fixtures as a base and then specializations for the environments.

[ashton]

This feature will be really useful if integrated with Doctrine DBAL, allowing us to load test fixtures into a test database, isolating test data, instead of dirtying the development database with test data, or purging develpment database everytime you ran your application tests.. That would be so useful..

[zodeus]

It would be nice to have some way of running certain fixtures base on some sort of criteria. However I think using an annotation such as @group on the fixture methods, with --include/exclude filter would be a better approach than separating them via directories or environments. This way you have a lot more flexibility when applying fixtures. For example you may have some fixture data related to users that you want applied to all environments but you only want to create users in test/dev.

[gentisaliu]

+1

[greg0ire]

@ashton : There is a solution for that! In your config_test.yml file, just write this:

doctrine:
    dbal:
        dbname:   %database_name%_test

[liuggio]

@greg0ire @ashton is better and cleaner create a parameters_test.ini for the test env.

[greg0ire]

@liuggio Why ? parameters* files are for things that change from machine to machine.

[liuggio]

For 2 main reasons
one explicit is always better than explicit
second in this way you have created a convention that is bad.

[greg0ire]

explicit is always better than explicit

you mean "explicit is always better than implicit" I suppose… how i using a file named config_test.yml not explicit ? The _test part feels pretty explicit to me.

And I can't see how I'm creating a convention, this file was here in the first place. Can't see how this is bad either. You need to make more compelling arguments (or to withdraw your previous claim, which would be the way to go IMO).

[liuggio]

ops yes was implicit.

Explicit = database_test, Implicit = something magic.
Convention = take the database name and add a test

you need to make more compelling arguments

I think you have all the arguments.

withdraw your previous claim

no comment.

[greg0ire]

I think you have all the arguments.

Yeah sorry, I did, but you have to admit they were not very clearly expressed.

I understand how I created a convention, but I don't think it is bad at all. By putting the %database_name% parameter in the parameters.yml file, symfony-standard lets people customize their database name on a machine level. But if they think some_name is a reasonable value, that won't clash with their existing databases, then maybe we can reasonably agree on the fact that some_name_test won't clash with an existing database either, can't we ? I think you're proposing to give extra flexibility that is not really needed.

Thinking harder, I think there is one case where I might consider your proposition : If I have a CI server that has databases and I don't want to have all databases suffixed with _test. Until then, I'll stick with convention over configuration, and the following principle:

Only put in the parameters.yml file things that change from machine to machine.

[stof]

People can do what they want to configure their test environment in their project, either using a suffix to their database name, or putting a separate parameter in their parameters.yml file for the test database.
In any case, configuring the database used in your test environment has nothing to do with this issue, which is about changing the fixtures based on the environment, and is not the responsibility of this bundle

[lavoiesl]

Closing since test databases are already possible and issues already exist for selective loading: doctrine/data-fixtures#169, doctrine/data-fixtures#140