knplabs / rad-fixtures-load Goto Github PK

Problem with installing bundle in symfony3.
in composer.json I have:
"symfony/symfony": "3.1.x-dev",
"knplabs/rad-fixtures-load": "dev-master",

Output:
Problem 1
- Installation request for knplabs/rad-fixtures-load dev-master -> satisfiable by knplabs/rad-fixtures-load[dev-master].
- Conclusion: remove symfony/symfony 3.1.x-dev
- knplabs/rad-fixtures-load dev-master requires symfony/http-kernel ~2.0 -> satisfiable by symfony/symfony[2.0.x-dev]

my_bundle.my_provider:
    class: My\Provider
    tags:
        - { name: knp_rad_fixtures_load.provider }

How do I get the locale in my custom provider or do I need to register multiple services for different languages? Any arguments I can use?

I apologize for the spammy issue, but as rad-fixtures-load is a one of the consumer of alice, I though worth informing you that the next version v3 is on it's way. So if you noticed something you would like to change at alice level, now is a good time :)

As a result

php app/console rad:fixtures:load

returns this

Catchable Fatal Error: Argument 1 passed to Nelmio\Alice\Fixtures::__construct() must be an instance of Nelmio\Alice\PersisterInterface, instance of Doctrine\ORM\EntityManager given

When resetting the schema, it is actually dropped and recreated using metadata of all classes. The problem is that it doesn't take into account all the changes that could have been done with migrations.

Instead, I think we should simply REMOVE all entries from the tables. That's actually what data-fixtures does.

As of now Alice fixtures must be placed under Resources/fixtures/orm.

Wouldn't it better to keep the DoctrineFixtures behavior which allows to specify the path where the loader is declared and with a default file path? And wouldn't it be better to keep the default path and make it configurable?

That would have the benefits to:

• ease the transition if previously using another bundle to do this kind of task
• keep the same convention while allowing one to define it's own convention and keeping the interesting feature you introduced which is loading fixtures for a given bundle
• being more generic and not too much Symfony specific

Besides for the filtering you're using a file extension convention system with .yml, .dev.yml, .prod.yml and so on. This is fine if you don't have too much files. If you have even just 10 files for each, it's much more practical to use separate folders. To retake the example of what you can currently achieve with hautelook/AliceBundle, you can have:

DataFixtures
├── Prod
|   ├── DataLoader.php
|   ├── ...
|   └── fixtures.yml
├── Inte
|   ├── DataLoader.php
|   ├── ...
|   └── fixtures.yml
└── Dev
    ├── DataLoader.php
    ├── ...
    └── fixtures.yml

And keep things clear.

Why such a weird name and not sticking to bundle's name conventions like AliceBundle or AliceFixturesBundle?

Otherwise great library, happy to have an alternative to Hautelook/AliceBundle which is more well designed! :)

If you combine manager and reset options the schema reset is executed on default manager because of incorrect service argument.