OroPlatform Forums

Covering OroPlatform topics, including community updates and company announcements.

Forums Forums OroPlatform Someone managed to upgrade ORO to 1.6.1 or 1.6.2 without any errors?

This topic contains 20 replies, has 2 voices, and was last updated by  Rodolfo 9 years, 2 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
  • #36817

    Rodolfo
    Participant

    Someone managed to upgrade ORO to 1.6.1 or 1.6.2 without any errors?

    I’m following this, but when I try to select an existing database, I always got this error, even passing the –force parameter:

    “Property Oro\Bundle\CalendarBundle\Entity\CalendarEvent::$contact_cdc90e7a does not exist ”

    So, any suggestion? How to update my platform and preserve all old data?

    Adding a new/empty database all works well..

Viewing 15 replies - 1 through 15 (of 20 total)
  • Author
    Replies
  • #36818

    Rodolfo
    Participant

    I don’t mind if I have to create a new database and re-sync all my websites. My only problem now is my TrackedEvents. I can’t lose these data.

    #36819

    ignat
    Participant

    Hi Rodolfo,

    I guess this kind of error can happen if Oro\Bundle\CalendarBundle\Entity\CalendarEvent is an “extended” entity, but as I can see that it’s “extended” only in master currently. Was this application being on master of oro/platform once?

    I remember I had same error during development when I was installing my application on 1.6.x using existing database that was created by application installed on master.

    I’ll try to reproduce this issue by upgrading from 1.6.1 to 1.6.2 and let you know.

    Thanks,
    Ignat

    #36820

    ignat
    Participant

    Could you please also provide dumb of all tables starts with oro_entity_*? I hope it can help to figure out what is happening wrong.

    Thanks,
    Ignat

    #36821

    Rodolfo
    Participant

    Hi Ignat,

    Thank you for your answer.
    Yes, you’re right. I didn’t know that I had to select the tag 1.6.1 when I installed. I thought that pulling from master would upgrade my system to 1.6.1, so I only noticed after tried to upgrade to 1.6.2. So, this installation are using EE v.1.6.0 from master branch. I also noticed that we have different files inside CalendarBundle\Entity comparing with 1.6.0 and 1.6.1.

    I sent the sql-dump in your e-mail.

    Thanks
    Спасибі

    #36822

    ignat
    Participant

    Rodolfo, to solve your problem you need to downgrade database of your application to 1.6.1 first. I can try to prepare SQL to accomplish this. I need to clarify few things. Do you have any custom entities in your installation? I can see references to “TrackingCustomer” in dump you’ve sent. Did you install any packages in your application?

    Thanks,
    Ignat

    #36823

    Rodolfo
    Participant

    Hi Ignat!

    I can’t downgrade because I’m already downgraded. I created this entity ‘TrackingCustomer’ but I’m not using it. Unfortunately the TrackingBundle is not extendable and I can’t use it. This is another feature request that should be good. We need more info in tracking events. Not only the product_id but brand, categories and product name. I was trying to modify the oro-tracking to get these info into separate fields.. I have a pull request on oro-tracking repo but still without any feedback. Anyway, this is a story for other topic..

    So, I can remove this entity anytime. Do you think this is affecting my upgrade from 1.6.0(master) to 1.6.2/1.6.1? Because the error logs are showing only CalendarBundle errors. I never used this Calendarbundle before..

    Maybe I should just sync everything again and create a fixture to load oro-tracking events? I noticed that we have the oro.tracking.processor.data, but how can I use it? I have 1 million events by now..

    My System Information Page

    ubuntu@ip-xx-xxx-xxx-xx:$ head CHANGELOG.md
    CHANGELOG for 1.6.0-RC1
    ===================
    This changelog references the relevant changes (new features, changes and bugs) done in 1.6.0-RC1 versions.

    * 1.6.0 (2014-09-30)
    * <b>New features.</b>
    The Enterprise Edition is built…

    #36824

    Rodolfo
    Participant

    ubuntu@ip-xx-xxx-xxx-xx:$ git status
    On branch master
    Your branch is up-to-date with ‘origin/master’.

    #36825

    ignat
    Participant

    Rodolfo, try this steps to downgrade your database and point your application on 1.6.2:

    1. Make a backup
    2. Switch to 1.6.1 and run composer update.

    3. Remove caches manually, rm -R app/cache/*
    4. Execute SQL queries in your DB https://gist.github.com/ignat-s/1b76c2ca508db77391dd
    In my case I wasn’t able to drop table oro_activity_list, please ensure that it will be dropped after this step because on update to versions above 1.6.2 you will have problems with it.
    5. Run app/console cache:clear –env prod
    6. Run app/console doctrine:schema:update –env prod –force
    7. Switch to 1.6.2 and run composer update.

    8. Remove caches manually, rm -R app/cache/*
    9. Run app/console oro:platform:update –env prod –force

    Now your application should be on 1.6.2.

    Thanks,
    Ignat

    #36826

    Rodolfo
    Participant

    Hi Ignat!

    Thank you again for all your help.
    On step 9, look what I got:

    php app/console oro:platform:update –env prod –force
    Process migrations…
    > Oro\Bundle\AddressBundle\Migrations\Schema\v1_2\ChangeAddressPostalCodeLength
    > OroCRM\Bundle\ContactBundle\Migrations\Schema\v1_9\ChangeContactAddressPostalCodeLength
    > OroCRM\Bundle\MagentoBundle\Migrations\Schema\v1_21\AddFields
    > OroCRM\Bundle\MagentoBundle\Migrations\Schema\v1_21\OroCRMMagentoBundle
    > OroCRM\Bundle\MagentoBundle\Migrations\Schema\v1_21\DropFields
    > OroCRM\Bundle\MagentoBundle\Migrations\Schema\v1_22\ChangeAddressPostalCodeLength
    > Oro\Bundle\MigrationBundle\Migration\UpdateBundleVersionMigration
    > Oro\Bundle\EntityExtendBundle\Migration\RefreshExtendCacheMigration

    [Doctrine\Common\Persistence\Mapping\MappingException]
    Class ‘Oro\Bundle\CalendarBundle\Entity\CalendarProperty’ does not exist

    oro:entity-extend:cache:clear [–no-warmup] [-h|–help] [-q|–quiet] [-v|vv|vvv|–verbose] [-V|–version] [–ansi] [–no-ansi] [-n|–no-interaction] [-s|–shell] [–process-isolation] [-e|–env=”…”] [–no-debug] [–jms-job-id=”…”] [–current-user=”…”] [–current-organization=”…”] [–disabled-listeners=”…”] command

    [RuntimeException]
    The command terminated with an exit code: 1.

    oro:migration:load [–force] [–dry-run] [–show-queries] [–bundles[=”…”]] [–exclude[=”…”]] [–timeout[=”…”]] [-h|–help] [-q|–quiet] [-v|vv|vvv|–verbose] [-V|–version] [–ansi] [–no-ansi] [-n|–no-interaction] [-s|–shell] [–process-isolation] [-e|–env=”…”] [–no-debug] [–jms-job-id=”…”] [–current-user=”…”] [–current-organization=”…”] [–disabled-listeners=”…”] command

    [RuntimeException]
    The command terminated with an exit code: 1.

    oro:platform:update [–force] [–timeout[=”…”]] [–symlink] [-h|–help] [-q|–quiet] [-v|vv|vvv|–verbose] [-V|–version] [–ansi] [–no-ansi] [-n|–no-interaction] [-s|–shell] [–process-isolation] [-e|–env=”…”] [–no-debug] [–jms-job-id=”…”] [–current-user=”…”] [–current-organization=”…”] [–disabled-listeners=”…”] command

    #36827

    Rodolfo
    Participant

    Sorry I forgot step 6. I’ll try again!

    #36828

    Rodolfo
    Participant

    app/console doctrine:schema:update –env=prod –force
    Schema update and create index completed.

    [Oro\Bundle\EntityConfigBundle\Exception\RuntimeException]
    A model for “Oro\Bundle\CalendarBundle\Entity\CalendarEvent::contact_cdc90e7a” was not found

    doctrine:schema:update [–complete] [–dump-sql] [–force] [–em[=”…”]] [-h|–help] [-q|–quiet] [-v|vv|vvv|–verbose] [-V|–version] [–ansi] [–no-ansi] [-n|–no-interaction] [-s|–shell] [–process-isolation] [-e|–env=”…”] [–no-debug] [–jms-job-id=”…”] [–current-user=”…”] [–current-organization=”…”] [–disabled-listeners=”…”] command

    #36829

    ignat
    Participant

    Was your application working previously on 1.6.1? Could you go through all steps and send result of query below before step with fail?
    SELECT data FROM `oro_entity_config` WHERE class_name = 'Oro\Bundle\CalendarBundle\Entity\CalendarEvent';

    #36830

    Rodolfo
    Participant
    #36831

    ignat
    Participant

    It should be like this https://gist.github.com/ignat-s/8b878c16bb910671b736 after step 4. Can you watch this value to determine on which step it obtained value that you sent?

    #36832

    ignat
    Participant

    I can reproduce this if on step 1 I will update to master. Please ensure that oro/platform, oro/crm and oro/crm-enterprise are updated by composer to 1.4.1, 1.4.1 and 1.6.1 respectively.

Viewing 15 replies - 1 through 15 (of 20 total)

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

Back to top