Questions & Answers

[jpee]

Hallo zusammen,

wir migrieren gerade mehrere Projekte auf eine einheitliche Datenstruktur und eine neuere FirstSpirit Version. Dabei wird auch unser Datenschema überarbeitet, so dass ein Standardimport und -export auf den ersten Blick nicht möglich erscheint.

Wir haben uns nun für folgendes Szenario entschieden. Wir haben alle bestehenden Daten in eine XML exportiert, die auch alle nötigen Metainformationen der einzelnen Felder enthält von den Entitäten. Als nächstes wollen wir diese Daten in unser neu entworfenes Schema importieren. Bisher taten wir dies über eine de.espirit.or.Session und erzeugten auf dem neuen Schema die Entitäten über die createEntity(String typ) Methode und passten die Werte über Entity.setValue() Methoden an. Dabei erzeugt FirstSpirit intern eine neue fs_id für jede Entität.

Wir würden jedoch gerne die alten fs_id's beibehalten. Jedoch konnte ich keine öffentlichen Methoden finden, um den Identifier (fs_id) zu manipulieren, was ja auch Sinn macht. Gibt es dennoch eine Möglichkeit die fs_id festzulegen? Gitb es alternative Wege?

Viele Grüße

Johannes

[feddersen]

Es gibt keine Möglichkeit die fs_id per API zu setzen, da die Verwaltung der Ids FirstSpirit obliegt. Sofern Sie die alten Ids behalten wollen, müssten Sie also an FirstSpirit vorbei arbeiten. Damit befinden Sie sich natürlich außerhalb jedes Supports und geschieht damit auf eigene Gefahr. Außerdem ist zu beachten, dass die fs_id innerhalb eines Schemas eindeutig sein muss. Sofern sie also mehrere Schemata zu einem zusammenfassen wollen, werden sie wahrscheinlich sowieso Konflikte bekommen. Generell würde man aber alle Datensätze über die API anlegen, sich das Mapping alte Id -> neue Id merken und dann per geeigneter SQL-Statements die IDs patchen. Dabei ist natürlich auch die temporale Datenhaltung zu beachten. Man sollte also wissen, was man tut.

[jpee]

Hallo Herr Feddersen,

wir haben nun begonnen den zweiten Weg einzuschlagen, jedoch komplett auf Api-Basis. Die Daten sind im Großen schon migriert und die Referenzen zwischen den Daten über die Api und ein Attribut fs_id_old wieder hergestellt. Lediglich die Referenzen in XML-Form, müssen noch hergestellt werden, wobei wir da die ersten Hürden auch schon bewältigt haben.

Größere Baustellen sind dann noch die Inhaltsseiten und deren Referenzen auf Tabellenvorlagen, welche über eine ID und nicht wie gedacht über den Referenznamen bestehen. Dies wollen wir ebenfalls über ein Mapping von den alten auf die neuen IDs wieder herstellen.

Ein großes Fragezeichen sind dann noch die Filter in der Struktur im Reiter Daten. Da wir bisher nicht wissen ob diese durch den Import übernommen worden sind, da ja der Bezug über den Inhalt zu den Tabellenvorlagen nicht mehr besteht, aber eventuell zu einem Entitätentyp, der wohl das einzige Anwendungskriterium für einen Filter darstellt.