Quote:
|
Originally Posted by Ksenia
If you have a live store on one hand ( which keeps generating new orders, customers, inventory changes) and upgraded store of a different version ( with new modules, changes to database, as well as, often, new data, such as products, images etc)on another hand, this 'synchronization tool' becomes a problem.
*which exactly type of data to move (customers? products? categories? orders?anything else?)
*how to define which data are new and require migration?
*what to do with different tables structure if the modifications/modules on dev copy affected the database?
*what to do with IDs if the same ones are present in two databases ( say , new product/user is created in live store and another new product/user with the same id - on dev copy) - overwrite, ignore? even if you personally do not add anything to dev copy, you should keep in mind that some people still tend to.
These are the problems I foresee at a first glance. If we ask upgrade team engineers, they will most probably give a dozen of other potential questions without clear answer.
Probably that's why even the upgrade engineer with more than 10 years experience often prefers this scenario:
#1 database is upgraded to target version on dev copy
#2 modifications and modules and design are applied. All the SQL changes are collected into a separate report.
#3 right before going live, the live store is being closed (and backup is saved), its database is taken as is and upgraded once again.
#4 SQL changes from #2 are applied to this database
#5 this fresh database with latest data is assigned to the upgraded software and the upgraded store replaces the old site.
Under no circumstances do I state that this is the only and best way. If we take each particular store separately, there may probably be much better solutions, and even this 'sync' script will work perfectly. But the more stores we need to cover ( and I guess you expect us to provide a solution which will work for most if not for all the users), the less is the possibility that such a synchronization will not result in new questions.
PS this is my personal opinion. Please do not consider it to be some kind of 'official comments'.
I hope Maxim will shed some light on this question later.
|
I agree the devt store should not be adding products/users/categories etc .
This sounds good in theory, but in practice there is no simple way to collect all the SQL changes ? Unless I missed something..... If this was possible it would certainly help.
I think an easy way is to provide simple export/import for all the major customer related items, such as :
Customers (you could select by last logon date maybe)
Orders (by date)
For products then I think you can maybe freeze new products, but you do need a simple import/export for prices and quantities in stock
This is not a total solution, but would be a practical approach. What we lack at the moment is the ability to import/export orders, quantities or prices in a simple manner (we can export orders, but not import, and we can import prices and quantities but not export in the same format).
By the way, if the advice is correct, then why can't we go from 4.4.5 to 4.6.0 by upgrading the DB and then connecting to a fresh instal of 4.6.0 instead of having to instal 4.5.0 and then apply an upgrade to get to 4.6.0?