jeking:
Never assume...you know what they say. That was the issue, I had not followed the proper naming convention. When I do, it works! Imagine that.
Follow-up question. Is there a way to export/import an product with attributes in one file? As it stands, it's two steps and two files currently.
Well, it got me thinking, thought perhaps after the last issue that was discussed in the instructions and overlooked would have prompted reading the instructions. :P
Yes it is possible, but is it truly desireable?
Small example, table 1 has two fields. One is the primary key, the other is the data. Table 2 also has two fields, one field is the primary key, the other is a data field but that field represents rows of data. So:
T1:
f1, f2
1, x
2, y
3, z
4, w
T2:
F1, F2
1, a,b,c
2, d,e,f
3, a,b,c
4, g,h,i
Now the resulting table (spreadsheet) for combining the two:
F1(f1), f2,F2split
1, x, a
1, x, b
1, x, c
2, y, d
2, y, e
2, y, f
3, z, a
3, z, b
3, z, c
4, w, g
4, w, h
4, w, i
Now, which one of these scenarios is easier to address, understand, and not necessarily make a mistake? Also, to accomplish the same functionality as existing, every upload of the attributes would require all attributes to be included every time in their entirety otherwise the absence of an attribute row would cause deletion of that attribute. Further, on each row every piece of data would have to be compared against the applicable table(s) for existence then update or add the additional data applicable. Sure alternatively can bring information into memory and do a comparison from that perspective instead of a sql statement for each evolution with the applicable data eventually applied with an appropriate sql statement.
This particular approach becomes resource and time intensive. If you have looked back a few pages you'll see that there is an add-on to EP4 to support the product type bookx. That code takes an approach like this. The individual that worked hard to put it together. Thing is, as anticipated because of taking this "do it all at once" approach the processing is slow. At one point the thought was expressed that it is somehow ZCs fault, but it has nothing to do with ZC as one can see in review of the EP4 code EP4 more directly interfaces with mySql than it does with ZC and ZC doesn't "control" mySql, just interfaces with it.
The approach that chadderuski took in development of EP4 more closely matches the original database tables and is why such large bulk changes can be made so quickly. There is a "trade-off" of using this approach. For onsey, twosey updates, it may not be worth the effort to split the input to such simple tables and it may be more worth doing the update within ZC. But in mass quantities, EP4 is a huge savings.... just sayin' :P
