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.
|
One thing not mentioned here and it will solve the problem of which data to sync - the dev store is there to develop the new store with new version, skin, look, fell, functionality, etc. The dev store is not there to make changes to products, categories, manufacturers, etc.. So your question what to sync or to sync new or ignore shouldn't be there in the first place.
When dev store is ready to go live sync from live store - overwrite completely
- products, categories, manufacturers and all related tables like discounts, coupons, special offers, images, zones, taxes, etc.
The dev store should not be adding, deleting or making any changes to store data.
When dev site is ready to go live do NOT sync from live store at all
- config, languages, modules and related tables
These tables hold the store config and settings so they should be taken from the dev store and not modified by the upgrade script.
It is that easy to determine what to sync and what not.
When syncing the actual store data do it by specifying exact fields in the query so even if for example products table has new fields added by a modification the query will not fail, also do it with "replace" and not with "insert". This has been a problem with many upgrades because XC sql patch uses "insert" and if a patch or modification has been applied years before with the same data the upgrade fails...
This all assumes once an upgrade is started it doesn't matter if it takes one week or couple months - no changes to live store config/settings should be made as this will not be transferred over and no changes to store data should be made in dev store (other than for testing) as this changes will be overwritten
Another one - how to determine what data is new and what not - this is design flow of XC.
- Orders can be determine as there is order date. But if you use AOM to modify the order 2 weeks from that date .....? Does the order date changes? Probably
- Customers cannot - there is no date when customer profile was created. There are dates for when it was last accessed or modified but no fixed date when it was created. Not a bug but design flow.
- There is no date when a product was created. There is date when it was last modified but no fixed date when it was created. And as many want to show new products using this date it so happens that this is wrong - create a product today, 2 months from now you see you made a spelling error in the description - correct it, the date changes and makes the product new again... Wrong. Serious design flow.