Fixtures dependencies

Hi there,

we ran into an issue yesterday and I wanted to clearify things here just to ensure this is not a bug…

For a bundle we created we added demo fixtures (under <path_to_bundle>/Migrations/DataFixtures/Demo/ORM/v1_0 like in the OroPlatform bundles). Running those went perfectly fine. Now we created new entities and wanted to extend demo fixtures. We introduced a new folder 1_1 and added a Fixture class in there. Running the fixtures load command works perfectly fine, if the “demo_data_version” of database table “oro_installer_bundle_version” is already set to “v1_0”. But: if we install our app on a new dev environment we run into the problem, that the fixture files are not processed in the expected order. Somehow, the 1_1 fixtures are loaded in a mixed order with tose of 1_0. As our 1_1 depend on the data of 1_0 fixtures we get an error. I tried to set a dependency via DependentFixtureInterface but that leads the dependent 1_0 fixtures file to be executed although 1_0 fixtures where already loaded before and the database indicates that. So either the fixtures loading for a clean new environment fails or the incrementation/delta approach for those environments where fixtures for v1_0 where already loaded.

So my question is: is the way fixtures loading is implemented right now in oro providing “incremental” fixtures? Is it supposed to provide that? Are we doing something wrong? Should we delete the old 1_0 fixtures and create completely new ones for 1_1? But that would need to also include deleting data that was added in 1_0 fixtures as well and I think at later versions that somehow gets ugly… And why would we use versions then at all?

Thanks for reply :)

And again thanks for your great effort and congrats to first stable version!

Topic

[Yevhen ShyshkinParticipant]

Hello, andesk.

In the latest release we already don’t have fixtures separated in the different directories – we have returned to regular Doctrine approach. Now information about loaded fixtures stored in table oro_migrations_data without bundle dependency and bundle version.

Could you try to adopt your fixtures to new implementation and test again with DependentFixtureInterface? To adopt data you simply have to move fixtures to Migrations\Data\Demo\ORM directory and set dependencies (see https://github.com/orocrm/crm/blob/master/src/OroCRM/Bundle/DemoDataBundle/Migrations/Data/Demo/ORM/LoadAccountData.php for example).

[andeskParticipant]

Thank you for the quick reply. It seems that the Fixture classes should work as before but without the version sub folders. Correct?

But as far as I can see in the installer the database structure is not created via doctrine commands anymore but inside migration:load command. As we have already introduced our own custom entities their tables in the database do not get created anymore as they did before (doctrine:schema:update). So we do have to create these tables via custom migration commands?

[Yevhen ShyshkinParticipant]

> Thank you for the quick reply. It seems that the Fixture classes should work as before but without the version sub folders. Correct?
Yes, fixtures itself will work exactly the same.

> the database structure is not created via doctrine commands anymore but inside migration:load command
That’s correct.

> As we have already introduced our own custom entities their tables in the database do not get created anymore as they did before (doctrine:schema:update). So we do have to create these tables via custom migration commands?
Yes, you have to implement migration script – see https://github.com/orocrm/platform/blob/master/src/Oro/Bundle/OrganizationBundle/Migrations/Schema/v1_0/OroOrganizationBundle.php for regular entities and https://github.com/orocrm/crm/blob/master/src/OroCRM/Bundle/AccountBundle/Migrations/Schema/v1_0/OroCRMAccountBundle.php for extended entities.
Also you should have a look at documentation about migrations https://github.com/orocrm/platform/blob/master/src/Oro/Bundle/MigrationBundle/README.md.

[andeskParticipant]

Thanks four your answer!

Wow, that’s a quite big change for fixtures/schema handling to rc3. Is it planned to provide a command or something that builds migration files (most important for database table schemas)? The initial work to create those files that were handled before by doctrine commands “out of the box” via the entity annotations is not thaaaat small I think…

But got it to work :)

[Yevhen ShyshkinParticipant]

Unfortunately, there is no such command for now, but thank you for feedback – I’ll add your proposition to our bug tracker.

[Dima SorokaKeymaster]

@andesk, a couple of reasons for such a big change (not supported by doctrine migrations):

• Versioned database schema migrations support on bundle level
• Possibility to manipulate with data during schema updates
• Flexibility on schema updates for a bundle

[andeskParticipant]

Thanks for clearification!

[Yevhen ShyshkinParticipant]

Also, for now you can use oro:migration:dump command, that build migration scripts for current DB structure.

[andeskParticipant]

So the workaround (to avoid writing migration methods ourself) for now could look like:
– use doctrine migrations to generate delta when changing entity schema
– apply that delta to database
– run oro:migration:dump command and copy the parts for the entity changes into a custom migration class/method

Right?

[Yevhen ShyshkinParticipant]

Yes.

There is even easier way to create migration script – you can update your DB with doctrine:schema:update, then run oro:migration:dump and calculate the difference.

To check whether your migration works fine you can revert DB to old state and run oro:migration:load / oro:migration:data:load.

In more general case you should use oro:platform:update command that execute all update operations including loading of fixtures.

[Author]

Replies