astember
Returning Observer

komplexe Attribute in Datenquelle importieren

Hallo zusammen.

Für den Import von Datensätzen via CSV, gibt es in der Community folgendes Beispiel -> csvimport2

Für einfache Anwendungsfälle wie Einfügen von Datensätzen mit String, Integer oder Date Attributen klappt dies auch ganz gut.

Wie sieht es aber mit komplexen Datentypen und verknüpften Datenquellen aus (XML,Entities)? Gibt es hier ggf. ein Beispiel oder "best practices" für solche Anwendungsfälle. Es geht im Speziellen um die Übernahme von Daten aus Datemodellen von FS4.2, in neue Datenmodelle FS5. Durch das Refactoring werden sich vorraussichtlich Tabellen und Spaltennamen und Formate ändern. Welche Funktionen und Formate sind für den Export dieser Daten geeignet (CSV,XML,...) und welche Funktionen der API eignen sich diese wieder einzuspielen?

Vielen Dank für ein paar Anregungen / Hinweise.

0 Kudos
6 Replies
astember
Returning Observer

Vielen Dank für die schnelle Antwort. Den genannten Beitrag hatte ich bereits überflogen. Zunächst aber beschäftigt mich der erste Teil meiner Frage, ob es eine generelle Empfehlung für das Austauschformat gibt.

Ich habe testweise einen CSV Export implementiert und erhalte nun die Objekte lediglich als String-Ausgabe:

Für das Attribut XML (Medienreferenz) ergibt sich in meinem Beispiel:

[anreiseflyer_how_to_find_us_1:MEDIASTORE_LEAF]@cbacb27[(undefined)]@3b6f73f8

Für die verknüpften Entities:

de.espirit.or.impl.EntityImpl@abef82a5{dcat_MBTEST,PERSISTENT,released,FS_ID=335104,FS_VALID_FROM=1372151190382,FS_VALID_TO=9223372036854775807,FS_RELEASE_TO=9223372036854775807}

Ich gehe allerdings davon aus, dass man diese Daten natürlich nicht weiterverarbeiten kann.

Ich wäre daher dankbar für einen kurzen Denkanstoß, welche Ausgabelogik- /format hier zu bevorzugen ist.

0 Kudos

Es gibt allgemeines Datenformat für den Austausch von Inhalten zwischen Versionen.

Es wäre aber vielleicht sinnvoll, das Projekt mit den Inhalten erst auf FS 5 zu aktualisieren, inkl. Umstellung auf die neuen Eingabekomponenten. Beim erneuten Speichern der Inhalte werden die Daten dann im neuen Format geschrieben. Dann haben die Inhalte das gleiche Datenformat und können einfach kopiert werden.

0 Kudos

Der Weg wäre sicher für eine "1:1 Migration" sinnvoll. Wir gehen allerdings von einer kompletten Neukonzeption aus, d.h alle Datenbankvorlagen werden neu bewertet und ggf. um Attribute erleichtert oder ergänzt bzw. wird es vorraussichtlich auch grundsätzliche Änderungen in den Datenmodellen geben, so dass wir nur Teildaten der Datenquellen übernehmen müssen. Ich bin daher von einer Art Mapping via Script auf das neue Datenmodel ausgegangen, da ich nicht weiß wie flexibel sich einmal importierte Datenbankschemas mit befüllten Daten in FirstSpirit nachträglich ändern lassen.

0 Kudos

Das Datenmodell kann man ja nach der Migration entsprechend neu erstellen und dann die Daten per Mapping vom alten Datenmodell in das neue Datenmodell kopieren. Das ist sehr einfach möglich, wenn sich die Eingabekomponenten nicht ändern (Also eine Überschrift ist immer noch ein Textfeld, Bildauswahl immer noch eine FS_REFERENCE). Soll aus einem Textfeld ein FS_REFERENCE werden, ist das natürlich aufwendiger.

Das klingt zumindest logisch und sinnvoll. Ich nehme es mal mit und werde es ausprobieren. Vielen Dank schon mal.

0 Kudos