OroPlatform Forums

Covering OroPlatform topics, including community updates and company announcements.

This topic contains 12 replies, has 3 voices, and was last updated by  topp 7 years, 6 months ago.

Starting from March 1, 2020 the forum has been switched to the read-only mode. Please head to StackOverflow for support.

  • Creator
    Topic
  • #33484

    jakabadambalazs
    Participant

    Hi,

    I was following the customization guide @ http://oroinc.com/orocrm/doc/current/book/customization

    When you are explaining how to dump the migrations to “dump the complete database schema” and then copy&paste the relevant content to my own migrations file – I checked and the command guide and I noticed that you can actually dump the migrations for a specific bundle.(app/console oro:migration:dump –bundle JABTestBundle).

    Q1: It is much more convenient. Is there a specific reason why you are dumping the entire database schema on the docs?

    Q2: The dumped migration class implements `Oro\Bundle\MigrationBundle\Migration\Installation` and not `Oro\Bundle\MigrationBundle\Migration\Migration` as documented. The Installation class extends the Migration class – so I believe this is due to an outdated documentation. Is this the case?

    thanks
    a\


    oro/platform(1.6.2) + oro/doctrine-extensions(1.0.7) + symfony/symfony(v2.3.27)

Viewing 12 replies - 1 through 12 (of 12 total)
  • Author
    Replies
  • #33485

    Alexandr Smaga
    Participant

    Hello @jakabadambalazs !

    A1: I think this feature was added later than documentation was written. So, you can use both ways.
    A2: Yes, documentation a little bit outdated. Actually this command generates installer instead of migration, but content is the same.

    Difference between installer and migration is that installer will be applied only during installation and will fix migration’s version on version that returned by getVersion method.

    #33486

    jakabadambalazs
    Participant

    Ok, thanks.

    I am looking at the AccountBundle where you have the Migrations/Schema/OroCRMAccountBundleInstaller class implementing the Installer (and supplying the “v1_5” in getMigrationVersion) and the version specific migration classes from v1_0 to v1_5 (implementing the Migration class) the in the corresponding subfolders.

    What is not clear to me is why is the content of the installer is the same as the migration v1_0. If during install the installer is executed why do we need a migration class with the same content?

    In my experience this often leads to human errors where we might update the installer but not the migration class or vice versa.


    oro/platform(1.6.2) + oro/doctrine-extensions(1.0.7) + symfony/symfony(v2.3.27)

    #33487

    jakabadambalazs
    Participant

    sorry(cannot edit previous post)[why?]

    So, to be clear:
    you say:

    “Difference between installer and migration is that installer will be applied only during installation and will fix migration’s version on version that returned by getVersion method.”

    So, this means that upon bundle installation the installer and ONLY the installer is executed and so it should contain the full code (entity configuration and whatever else). At the end it registers the current migration version supplied by the installer (through getMigrationVersion) into oro_migrations table (INSERT INTO oro_migrations (bundle, version, loaded_at) VALUES ('JABTestBundle', 'v1_0', '2014-10-24 11:25:58')).

    When my bundle is updated, Oro will check at which migration version the bundle is and execute all the migrations in the bundle (supposedly v1_1) which should have only the changes with respect to what has been done in the previous migrations.

    Is this correct?

    If it is, then I do not understand why migration v1_0 is needed.


    oro/platform(1.6.2) + oro/doctrine-extensions(1.0.7) + symfony/symfony(v2.3.27)

    #33488

    Alexandr Smaga
    Participant

    sorry(cannot edit previous post)[why?]

    Time when editing allowed is limited(I think about 15 minutes)

    So, this means that upon bundle installation the installer and ONLY the installer

    No

    Idea here is following:
    When you start development of new bundle(with some entity) it’s not required to implement installer, because it will identical to migration of v1_0.
    So, during installation of CRM and during update(example: bundle install on already installed CRM) will be only v1_0 migration executed.

    Then let’s imagine that some time later you decided to add some fields to your entity and created migration v1_1, so during installation of CRM or installation of your bundle 2 migrations will be executed. Then you decided to remove some field and create third migration. Those 3 migrations will impact on installation performance. So better to group this 3 migration into installer that will be executed once and will do same things as those 3 migrations.

    #33489

    jakabadambalazs
    Participant

    Got it! Thanks!


    oro/platform(1.6.2) + oro/doctrine-extensions(1.0.7) + symfony/symfony(v2.3.27)

    #33490

    jakabadambalazs
    Participant

    Time when editing allowed is limited(I think about 15 minutes)

    Yes now I see, but I think it is more like 5 minutes


    oro/platform(1.6.2) + oro/doctrine-extensions(1.0.7) + symfony/symfony(v2.3.27)

    #33491

    jakabadambalazs
    Participant

    So, let’s say I have 5 migrations v1_0..v1_5 and also an Installer.

    During installation:
    If my Installer getMigrationVersion returns v1_3 would the installerBundle(is this the one responsible for the installtions?) see that thare are also v1_4 and v1_5 and execute both of them?


    oro/platform(1.6.2) + oro/doctrine-extensions(1.0.7) + symfony/symfony(v2.3.27)

    #33492

    Alexandr Smaga
    Participant

    Yep!

    #33493

    jakabadambalazs
    Participant

    ok – that makes sense
    thanks


    oro/platform(1.6.2) + oro/doctrine-extensions(1.0.7) + symfony/symfony(v2.3.27)

    #33494

    topp
    Participant

    Hi,

    So better to group this 3 migration into installer that will be executed once and will do same things as those 3 migrations.

    I don’t get why an installer would “do the same things”.
    If i drop an existing column that would result in a dropColumn() statement in a migration while it would just not exist in an installer which freshly creates a table.

    But my actually question is: There is no automation for migration class generation, you really expect us to setup migration classes manually?
    What i am looking for is similar to: http://symfony.com/doc/current/bundles/DoctrineMigrationsBundle/index.html#generating-migrations-automatically
    but not just plain sql statements maybe…

    Thx
    Tom

    #33495

    jakabadambalazs
    Participant

    hi @topp,

    1) well you’re right and wrong – the installer should reflect the totality of all the migrations.
    So if you make 2 migrations for your bundle
    v0.1 – add column
    v0.2 – remove column
    Then you are right – your installer in v0.2 would not have the ->addColumn() statement

    if in v0.3 you realize that the column was really cool and you add it back, you’d add the

    in both the installer and the v0.3 migration class

    The way you should look at the installer class that it should represent the current state of your scheme while the migration classes need to reflect the changes made to the scheme since the last migrations.

    This way for first installs (v.0.3) you do not add+remove+readd the column but execute the installer and add it. If you upgrade, depending on what version you are on, Oro Platform will work out which migrations are needed to get to the current state.

    2) yes there is – check here: https://github.com/orocrm/platform/blob/master/src/Oro/Bundle/MigrationBundle/README.md
    – read on oro:migration:dump


    oro/platform(1.6.2) + oro/doctrine-extensions(1.0.7) + symfony/symfony(v2.3.27)

    #33496

    topp
    Participant

    Well that is the problem: “Also there is oro:migration:dump command to help in creation installation files”

    Indeed it just creates an installation but not a migration.
    So we have to setup migration classes manually or am i missing anything?

    thx & cheers

Viewing 12 replies - 1 through 12 (of 12 total)

The forum ‘OroPlatform – Programming Questions’ is closed to new topics and replies.

Back to top