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, 3 months ago.
Starting from March 1, 2020 the forum has been switched to the read-only mode. Please head to StackOverflow for support.
- CreatorTopic
- December 2, 2014 at 11:41 am #36817
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..
- CreatorTopic
- AuthorReplies
- December 2, 2014 at 8:38 pm #36818
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.
December 3, 2014 at 5:31 am #36819Hi 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,
IgnatDecember 3, 2014 at 5:55 am #36820Could 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,
IgnatDecember 3, 2014 at 8:08 am #36821Hi 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
СпасибіDecember 4, 2014 at 3:51 am #36822Rodolfo, 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,
IgnatDecember 4, 2014 at 7:41 am #36823Hi 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..
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…December 4, 2014 at 7:48 am #36824ubuntu@ip-xx-xxx-xxx-xx:$ git status
On branch master
Your branch is up-to-date with ‘origin/master’.December 4, 2014 at 8:04 am #36825Rodolfo, 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.1234567"require": {"oro/platform": "1.4.1","oro/crm": "1.4.1","oro/crm-enterprise": "1.6.1"},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.1234567"require": {"oro/platform": "1.4.2","oro/crm": "1.4.2","oro/crm-enterprise": "1.6.2"},8. Remove caches manually, rm -R app/cache/*
9. Run app/console oro:platform:update –env prod –forceNow your application should be on 1.6.2.
Thanks,
IgnatDecember 4, 2014 at 10:30 am #36826Hi 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 existoro: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
December 4, 2014 at 10:34 am #36827Sorry I forgot step 6. I’ll try again!
December 4, 2014 at 10:55 am #36828app/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 founddoctrine: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
December 4, 2014 at 11:11 am #36829Was 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';
December 4, 2014 at 12:08 pm #36830This is the data now:
https://gist.github.com/rodolfobandeira/cb056590af9971dcb22cAnd here without decoding:
https://gist.githubusercontent.com/rodolfobandeira/9f6bd0c7c53a987e2b0f/raw/8e36a945fb67d2d8d8fb5e129f01ea8e22cd215a/gistfile1.txtI’ll restore all backups and reproduce the steps again…
December 4, 2014 at 12:32 pm #36831It 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?
December 4, 2014 at 12:35 pm #36832I 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.
- AuthorReplies
The forum ‘OroPlatform’ is closed to new topics and replies.