identifier4 fehlt

Fragen und Antworten
1

Hallo,


ich würde gern einen Datastore-Update fahren über einen Querverweis. Jedoch gibt es nur 3 identifier, die ich aber benötige.

Das Datastore-Feld active soll mit dem Wert der Abfrage-Feld active belegt werden, wenn das Feld ParentIDPresta gleich dem Abfrage-Feld-Parent der Abfrage PrestaShopGetParents ist.


jobid 3cf9403e-fc5f-11e7-bbbf-901b0ea49fee

2

Hallo ennkii,

ein identifier4 ist leider aktuell nicht möglich. Wir nehmen das aber mit auf die Wunschliste, da mittelfristig an einer neuen Datenbank-Technologie gearbeitet wird, womit das möglich werden könnte.

3

Eine weitere Alternative wäre über den Step KeyValueSpreadsheet. Damit könnte man sich "on the fly" eine Art Mappingset erstellen, welches man dann in einem folgenden SpreadsheetMapper verwenden kann.

4

Sorry wir verstehen es nicht.

1. Mappingsets gehen nicht zum Indentifier, nur von Spalte zu Spalte - jedenfalls mit dem Datastore Mappingset Builder beta

2. KeyValueSpreadsheet wie soll das gehen
Datastoresearch
danach dann key ist dann Indentifier1 und value dann PrestaParentId (indetifier4)
dann DatastoreWrite mit mappingset aus KeyValueSpreadsheetaber wie??

5
Sorry aber es funkt immer noch nicht. In dem Mappingset kann ich doch nicht auf die Zielspalte zugreifen, dass ist ja grundsätzlich uner Problem.

6

zum KeyValueSpreadsheet:

Ja, fast genau so:


1. Datastoresearch
2. KeyValueSpreadsheet: key=identifier4 (PrestaParentId), value=Indentifier1

3. SpreadsheetMapper: dort in der Spalte, wo der identifier1 gebraucht wird ca. folgendes machen:


${map@KeyValueSpreadsheet_1.get(spalteInDerPrestaParentIdSteht)!}


Dadurch sollte für die PrestaParentId der entsprechende identifier1 ausgegeben werden.


4. DatastoreWriter mit dem Spreadsheet aus 3.


Die Idee von FrontTool geht in eine ähnliche Richtung und zwar per Default-Mappingset zu erstellen (per Hand oder per AddUpdateMappingset ...oder vielleicht auch per Datastore Mappingset Builder... ). Dort würde man für jede PrestaParentId den identifier1 hinterlegen z.B.:

PrestaParentId1=123

PrestaParentId2=234

usw.



Am Ende ist die Idee von allen Ansätzen die gleiche. Man baut sich eine Übersetzungstabelle in der PrestaParentId auf identifier1 "gemappt" wird. Der Querverweis ist von der Sache her nichts anderes, nur dass der direkt in Datastores reingucken kann.

7
Hallo,

ich verstehe, der Ansatz von @Synesty Sales, dass ist natürlich flexibler aber zum
1. bekomme ich eine Error
Script error: You have used a variable (map@KeyValueSpreadsheet_39.get) which does not exist.
Das KeyValueSpreadsheet_39 und das Feld key existiert aber, hier ein Auszug:
key value 1 9191 1 9192 1 9193 1 9194 2 9195 2 9196 2 9197 2 9198 3 9199 3 92002. Daran sieht man auch das natürlich das Mappingset für eine PrestaParentId immer mehrere Varianten mit verschiedenen Indentifiern1 hat. Das sollte aber kein Problem sein?
3. kommt nach dem KeyValueSpreadsheet auch ein Error
Map exceeds maximum of 150kB - Reduce the lenght of your keys / values to store more rows/entries.

8
Noch ein anderer Ansatz, leider waren meine Tests erfolglos.
Search Datastore, wechsel des identifier2 von bisher VariationModel zu ParentIDPresta. Dann mein Update und danch wieder zurück.

9
Letzter und wahrscheinlich einfachster Ansatz
Beim Import würde ich jetzt schon ParentID und VariationID als Indentifier zusammen ablegen. Bsp. 1-789.
Jedoch wissen wir nicht, wie beim Stock- und active-Update dann der unnötige Teil (-789) entfernt werden kann
oder ein Platzhalter die VariationsID ersetzt Bsp.: ${id_product!}-%
oder alles ggf. über einen Querverweis geklärt wird .