mc12345678
commented
8 years ago A manual process to accomplish this is provided below as provided in the EasyPopulate V4 forum post
If store 1 has a unique model # for each product and the option names are unique (only one instance of the option name in all of the option names), then the import of the first two files has populated store 2 with all of the attributes of the product from store 1. What is missing though is the detail associated with each attribute. So, to update store 2's attribute details, a file has to be generated such that each of the four primary keys match an existing entry in the attributes table. So, how to accomplish this?
Here's what I see. It is possible at this point to export the detailed attributes from both store 1 (already have) and store 2. Each of these has text versions of the option names and option values names. The model number is whatever it is and the products_attributes_id is expected to be unique to each store.
So what I would do would be to sort the data in both detailed lists on three fields in the same "order" (either ascending or descending but make it the same on both spreadsheets) such that sorted by products_model, then option_name, and then option_value_name. Then pick the method/location desired, but the goal is to eliminate from the list for store 2 any product that is not in store 1. This would be by a comparison of products_model. For now, also eliminate from store 1 any row that doesn't have a model #. (will have to address that separately because really that product never got uploaded to store 2, but at least the list should be small.) Then begin moving entire rows as necessary such that the row in store 1 lines up with the row of store 2 by first comparing option names then option value names. Provided nothing "new" has been done with store 2, these should line up exactly. Then once all have been lined up, copy the primary field data from store 2 over the data of the same field for store 1. Once all four columns are copied, save the file as the csv file to be uploaded and then imported into store 2.
Obviously through this process you'll want to save a backup of the file(s) to minimize any rework. Keep in mind the filenaming convention needed by the plugin.
And with that, the new file when uploaded and imported to store 2 should have store 2 with the same attributes and details of attributes as store 1.
Import of data using EP4 generally uses human readable information to support import of data. Examples are the products_model field for products and the combination of option_name and option_value_name for basic attributes.
Detailed attributes though "still" use the specific database provided primary keys to match the detailed attribute information with the applicable database entry. While this is or can be an important feature for updating a database's specific attribute information because of the constraints applied in using a specific option name that has the same content of another, it also can be a drawback if detailed attribute information is collected from an alternate source (different database) and attempted to be pushed against the current database.
Implementation of such a change though could become tricky as if two option names are generated for a product to have the same name (not exactly likely, but something with which to contend) then the wrong attribute appears could be updated with information. (More consideration is needed for that possibility.) At any rate, if applying this type of change, then when a query to the database identifies that a match can occur in more than the one primary key, then each option of that primary key's match needs to be cycled through to validate that no match exists before an "error" is generated. As such each possible combination within the database must be attempted when doing this review/comparison to identify the presence of the specific attribute entry. This certainly would be a point of identifying what goes best, more memory on a variable or more run time on one or more queries. Ideally some sort of balance can be found.
Currently the primary reason to support this is to make EP4 a better program to transfer information from one database to another instead of upgrading/importing the database.