Dynamic namespace

[MassiveHiggsField]

Hi there,

i've tried to upgrade to version 3.x but i can't find a way to make it compatible with our setup. Our application has different tenants and we switch between them through an ENV variable we're setting through apache (or for cli on the shell).
Every tenant has its own bundle with its own fixtures. Before we just did something like this:

#~ php bin/console doctrine:fixtures:load --fixtures=src/MyApp/${tenant}Bundle/Fixtures/Entity/

Where "${tenant}" would get replaced by ant with the value of env variable TENANT, so it would be called like this:

#~ TENANT=tenant1 ant db-reset
#~ TENANT=tenant2 ant db-reset
#~ TENANT=tenant3 ant db-reset

But since the "--fixtures" has been removed, i can't find a way to load different fixtures based on an environment variable.

[Invis1ble]

+1, I have different fixtures for different environments, after upgrade I can't load specific fixtures.

[roberto910907]

I was wondering if it's possible to add the --fixtures at the command and pass it as param to $fixtures = $this->fixturesLoader->getFixtures() and inside the method getFixtures() filter just the fixtures that have been registered in the service container(in that class $this->fixtures already contains all the fixtures added in container compilation which route path coincide with the path provided in --fixture options.

What do you think?, Sorry for my english.

[alcaeus]

I've given this some thought - that was an oversight in the implementation that neither @weaverryan nor I thought of.

Since the service container injects all services with a specific tag into the loader, there would either have to be multiple fixture loaders (meh) or have one loader that is able to distinguish different fixture sets using a tag:

<!-- Will be added to the "default" set due to autoconfiguration -->
<service id="DefaultFixture" />

<!-- Will be added to the "special" set -->
<service id="...">
    <tag name="doctrine.fixture.orm" set="special" />
</service>

You could load individual fixture sets by passing the name of the fixture set to the doctrine:fixtures:load command.

For those missing that functionality, would the above approach work for you?

[DylanGD]

Hi,

Same issue here...
How to specify the fixture set to the doctrine:fixtures:load ? Any example ?

Thanks

[alcaeus]

Have you read my comment above yours? I've made a suggestion and am waiting for feedback from people who need this feature.

[DylanGD]

Yes, just created and injected that :

<services>
        <service id="CoreBundle\DataFixtures\ORM\LoadUserData" />

        <service id="AnotherBundle\DataFixtures\ORM\LoadTestData">
            <tag name="doctrine.fixture.orm" set="myTest" />
        </service>
</services>

I don't know how to pass/use the fixture set "myTest" to the : doctrine:fixtures:load

[alcaeus]

This is a suggestion of an implementation I'd like to have feedback on before I work on the implementation. This does not work in 3.0.

[craue]

@alcaeus, if the --fixtures option won't be readded (and I doubt it will), your proposal of defining various sets would at least be a way to solve this issue. So I'm 👍.

[alcaeus]

It could also be named --fixtures - it's just that folders no longer work when the loader doesn't deal in files, but services: what definitely won't (can't) be readded is --fixtures=path/to/fixtures.

[craue]

@alcaeus, you know what I mean. 😏 And I wouldn't call the new option --fixtures then.

[weaverryan]

Yea, I like the tag option. Actually, I thought this might be needed, and was thinking the same. You can even easily use the auto-registration syntax to give one specific directory a special tag (like we do with controllers).

[craue]

Any progress, @alcaeus?

[weaverryan]

@craue would you be willing to make a PR? Honestly, @alcaeus doesn’t even use this bundle, he’s just nice enough to review PR’s, merge and tag releases. So, we can’t ask too much of him :).

[alcaeus]

Ha, I was just about to write a reply.

As Ryan pointed out, I hardly use this bundle, and the one project that uses it still works with the 2.x release line and also doesn't need to support multiple fixtures.
I'm most likely not going to have the time to implement this in the next few weeks. Contributions are always welcome - the idea is out there and seems to be what people want; implementing it shouldn't be too hard if you need it.

[craue]

I just thought @alcaeus was waiting for more feedback before starting to work on it. 😏 But I won't have time for this currently either.

[bicpi]

I have a similar issue that prevents migration to the new 3.0 version.

I have kind of a modularised monolith and each module has it's own fixtures directory and also uses its own database. With the previous directory approach similar to the one described above I was also able to select the appropriate doctrine connection.

bin/console doctrine:fixtures:load --fixtures src/foo/DoctrineFixtures --em foo
bin/console doctrine:fixtures:load --fixtures src/bar/DoctrineFixtures --em bar

Now in version 3+ without the --fixtures option I'm wondering how I can load fixtures in the same Symfony project that uses multiple database connections.

The load command allows me to pass the entity manager but then it seems to be used for all fixture services. I could pass the appropriate entity manager to the fixture services via DI but this somehow makes the object manager argument useless that is passed to the load(ObjectManager $objectManager) method and I guess purging the database won't work because that is done inside the command's execute() method and then only done for the entity manager that is passed to the command. So not all tables of all connections are purged.

[alcaeus]

@bicpi would the suggestion in #219 (comment) work for you? You'd have to manually specify the entity manager, it would just reintroduce the missing fixtures option (or actually a replacement for it).

I'm not sure if there should be a connection between fixtures and the EM (apart from the command), but then I've never had a use-case for multiple entity managers.

[bicpi]

@alcaeus I guess this should work and somehow look like this for my use case, right?

bin/console doctrine:fixtures:load --fixtures foo --em foo
bin/console doctrine:fixtures:load --fixtures bar --em bar

First command would load all fixture services tagged foo and use the correct foo entity manager for purging and loading. Same goes for the second command using the services tagged bar with the bar entity manger.

[Taluu]

Or maybe setting the em in the tag could do the trick too, right ?

<tag id="doctrine.orm.fixtures" set="foo" em="foo" />

defaulting to the default entity manager ?

I'll try to implement this if I ever get some time...

[alcaeus]

I was about to say that there's no guarantee everything created by that fixture should be written by that fixture, but we make the assumption already. So yeah, the em option would make sense:

• if set, it would always use that entity manager
• if not set, it would use the entity manager defined via the em option in the command

Sounds good 👍

[Taluu]

It would be the reverse actually ; if set, use that em by default (otherwise use the default entity manager), and can be overridden by the option --em

[bicpi]

@Taluu Sounds correct that a CLI option always overwrites the given configuration, yes. If not set at all, the default entity manager is used.

[alcaeus]

Ah, I understand. Yeah, makes sense as well. I don't use either, so I'll let people that have a use-case worry about this 😉

[derekparnell]

Does anyone have a link as to why this option was removed? I'm trying to figure out what it gains us as opposed to the detriment of not having it.

[strawburrypokki]

See #219 (comment). Removing the feature was an oversight.

[weaverryan]

Yep, we just need a PR to bring it back - is like to have it too, everyone is busy.

If you want it, please add it! :)

[grzegorztomasiak]

I have just ran into an issue, unfortunately switching back to the version where --fixtures was supported.

[rumours86]

I've created a PR: #250

[danaki]

I need some fixtures to initialize an empty database and some for tests for DRY. Is this issue frozen?

[TerjeBr]

@danaki This issue is open. You are welcome to submit a PR for it if you like.

[EliasDeVos]

hi @alcaeus and @weaverryan, i was looking to make a pull request for this using the tags.
But i have the following issue.
The fixtures get loaded here using the default tag here
But the option --fixture would be passed to the command and much later after this loading has already happend.
I also don't think i can access the tags of the fixtures at runtime.
Could you just point me in the right direction how to get the passed tag (--fixture) in the FixturesCompilerPass (if this is even possible)

[alcaeus]

The fixture loader will need to remember all the fixtures along with their tags and then handle the tags later when fixtures are loaded.

[TerjeBr]

This issue will be resolved in PR #260

[alcaeus]

Closing here to consolidate discussion to #260.

[malutanpetronel]

I've given this some thought - that was an oversight in the implementation that neither @weaverryan nor I thought of.

Since the service container injects all services with a specific tag into the loader, there would either have to be multiple fixture loaders (meh) or have one loader that is able to distinguish different fixture sets using a tag:

<!-- Will be added to the "default" set due to autoconfiguration -->
<service id="DefaultFixture" />

<!-- Will be added to the "special" set -->
<service id="...">
    <tag name="doctrine.fixture.orm" set="special" />
</service>

You could load individual fixture sets by passing the name of the fixture set to the doctrine:fixtures:load command.

For those missing that functionality, would the above approach work for you?

what means there set "special" ?

[TerjeBr]

what means there set "special" ?

When this feature was implemented we renamed "set" to "group". So it will now be group="special" in the example from alcaeus. ("special" is just the name of the special group of fixtures in that example.)

Read more about this feature here:
https://symfony.com/blog/new-in-fixturesbundle-group-your-fixtures